Emacs syntax for filenames to mean "absolute location on the current remote host"?

[Jim Porter]

In Emacs, is there a way of spelling a file name to mean "an absolute 
name on the current remote host"? We have a way of spelling an absolute 
name on the local host ("/foo/bar"), and an absolute name on a specific 
remote ("/method:host:/foo/bar"), but I'm not aware of a way to make a 
string that means the equivalent of:

  (concat (file-name-remote-p default-directory) "/foo/bar")

Do we have a syntax for this? If not, could we add one? Maybe something 
like "/.::/foo/bar"? That would be a remote file name with the method of 
"." - i.e. "the current method" and no hostname (it would be inferred 
from the current remote).

----------------------------------------

If you'd like to know why I'm asking, read on. But be warned: I'm still 
trying to reason through all the logic here myself, so this may be a bit 
confusing (it certainly is for me!).

This is relevant for Eshell. In Eshell, you SSH into other hosts simply 
by using "cd /ssh:user@host:~". This is very convenient, but it produces 
some odd effects: when you're on a remote host like this, the meaning of 
"/foo/bar" is ambiguous. If you pass that to a command, it could mean:

  1) "/foo/bar" on your local filesystem (when the command is an Emacs 
Lisp function)

  2) "/foo/bar" on "host" (when the command is an external process)

To make matters more confusing, some Eshell commands implemented in Lisp 
will fall back to an external process if the Lisp version can't do what 
you asked, meaning that you need to know Eshell *very* well to be sure 
what will happen in these cases.[1]

To get around this, what if Eshell had a way of unambiguously referring 
to absolute file names, whether on your local system or the current 
remote host? For the local system, we already have a syntax available: 
quoted file names (e.g. "/:/foo/bar"). However, we'd need one for the 
current remote host too (see above).

As an addendum: it would be nice to have "/foo/bar" be usable too (i.e. 
not have this weird inconsistency). However, I think we'd need to 
perform some translations in Eshell to make this work, and I think 
that'd need to be defined on a per-command basis, so there would end up 
being cases where that broke. Unambiguous syntaxes would let us avoid 
that in the general case (at the cost of more typing).

[1] There's an optional Eshell module called "Electric Slash", but it 
doesn't handle this more-complex scenario.