bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong

["Drew Adams" <drew.adams@oracle.com>]

> OK, that makes sense since older versions did not support
> user-name completion.  Now you say that (read-file-name-internal "~"
> 'file-exists-p nil) returns "~/dradams/" and I can't understand where
> the additional slash comes from.
> 
> Also arguably, "~/" should also be a completion candidate, so 
> the above calls should not complete to "~dradams/" but to "~"
> (the common prefix between the two possible completions).

I cannot speak to why the / is included or why ~ is not considered the common
prefix.  Whoever implemented this change might be able to answer that.

To me, the important point in this bug report is that there is no such
directory: ~/dradams/.  And there is no such directory ~dradams either.
Returning either of those as a valid completion for a file/dir name is just
plain wrong, I think.

There is a directory that corresponds to ~.  It is the HOME (env var) directory,
which in my case is c:\.

Seems like perhaps something that might be relevant for Unix/GNU/Linux has been
inappropriately applied to Windows too.  Dunno.

I do not see why user-name completion (whatever that might mean for
Unix/GNU/Linux file-name completion) is involved at all on Windows.  The user
login name has nothing to do with the user's home directory.