On the contrary, the bash behavior is exactly what you should
expect.

If you go through the steps, it should become obvious why you get
the results you do.

The here-string contents are

1
2
3

which are presented to the read builtin on its standard input.

The read builtin reads one line, or until it encounters the
delimiter, which in this case is the same thing.

That line is `1'.

read then attempts to assign the contents of the line, after it
performs a form of word splitting, to the variables supplied as
arguments. So `a' gets `1', and that consumes the line.

Since there are more variables than fields in the line, the
remaining variables get assigned the empty string. That means
`b' and `c' are ''.

This was broken until bash-4.4-beta.

Versions before that word-split the word in a here-string,
despite the documentation saying that it did not. The effect of
this was to change IFS characters in the expanded string to
spaces, so the contents of the here-string would be

1 2 3

in bash-4.2. Look at

https://lists.gnu.org/archive/html/bug-bash/2015-09/msg00022.html

for the report.

When I changed the behavior to match the documentation, and
removed the word splitting, the contents of the here-string
became

1
2
3

You can see why b is assigned the empty string.

Your final example doesn't tell `read' to use newline as a
delimiter; it tells it to use `\'. If you want to use newline,
you need to specify it as -d$'\n'. `read' doesn't perform that
kind of translation on the argument to `-d' itself.