Yes, it's expected.
We say that Ctrl-D makes
cat see "end of file" in the input, and it then stops reading and exits, but that's not really true. Since that's on the terminal, there's no actual "end", and in fact it's not really "end of file" that's ever detected, but any
read() of zero bytes.
read() system call doesn't return zero bytes except when it's known there's no more available, like at the end of a file. When reading from a network socket where there's no data available, it's expected that new data will arrive at some point, so instead of that zero-byte read, the system call will either block and wait for some data to arrive, or return an error saying that it would block. If the connection was shut down, then it would return zero bytes, though.
Then again, even on a file, reading at (or past) the end is not an interminably final end as another process could write something to the file to make it longer, after which a new attempt to read would return more data. (That's what a simple implementation of
tail -f would do.)
For a lot of use-cases treating "zero bytes read" as "end of file detected" happens to work well enough that they're considered effectively the same thing in practice.
What the Ctrl-D does here, is to tell the terminal driver to pass along everything it was given this far, even if it's not a full line yet. At the start of a line, that's all of zero bytes, which is detected as an EOF. But after the letter
b, the first Ctrl-D sends the
b, and then the next one sends the zero bytes entered after the
b, and that now gets detected as the EOF.
You can also see what happens if you just run
cat without a redirection. It'll look something like this, the parts in italics are what I typed:
When Ctrl-D is pressed,
cat gets the input
foo, prints it back and continues waiting for input. The line will look like
foofoo, and there's no newline after that, so the cursor stays there at the end.