The problem is in the server, not the client.

That's incorrect.

   The close should be queued by the remote server only after the
   remote server has recieved confirmation that the packets have
   arrived at the client.

   By default, this is not how things work with sockets.

That's analogous to stating that Berkeley TCP does not implement TCP
correctly.  At least in this case, that's not true.

The problem is that the client is closing the connection.  If the
telnet client's stdin gets an EOF, one might expect it should at most
close the write side of the TCP connection (i.e. use the shutdown(2)
system call).

With a more reasonable protocol, you'd expect the half-close to be
propagated to the server, and the server would notice it and shut down
if appropriate.  However, TCP doesn't have a half-close mechanism.

The telnet client should at least have an option to not shut down if
it gets EOF from stdin.  It's not clear to me whether or not that
should be the default.