The two paths are explained in
     :help after-directory

---------------
The problem seems to be the difference between so-called "rooted" and 
"unrooted"
logical names; it seems that vms_unix_mixed_filespec() does not recognise this
difference currently.

An unrooted logical name:    ulog:foo.txt            (sys$login:foo.txt)
A rooted logical name:       rlog:[bar.baz]foo.txt

A rooted logical is a bit like a logical device; it can be followed by a
directory path in brackets ([bar.baz] or <bar.baz>). An unrooted 
logical is NOT
followed by a directory path. Furthermore, it can have multiple 
translations (as
described in Ticket #10).

---------------
The path SYS$LOGIN:VIMFILES/AFTER uses an unrooted logical. However,
vms_unix_mixed_filespec() translates it to

     SYS$LOGIN:[.VIMFILES]AFTER

This is wrong, because this path appears to contain a rooted logical.

Then, decc$translate_vms() fills in the default values (based on the default
directory). So, given that my default directory is

     $ show default
       MYDEVICE:[A.B.C.D]

decc$translate_vms() translates this to

     /sys$login/a/b/c/d/vimfiles/after

which is wrong (very different from the intention of 
SYS$LOGIN:VIMFILES/AFTER).

---------------
I think the solution is that vms_unix_mixed_filespec() does the following:

     1) extract the portion of the path up to the last colon (:) or closing
        bracket (] or >) literally (i.e. do not translate the [bar.baz] to
        bar/baz yet
     2) let decc$translate_vms() turn this into a Unix path
     3) then append the rest of the path (left after point 1)
     4) let decc$to_vms() turn it into a VMS path again

    (5) put in a comment somewhere, making the assumption (which is 
already being
        made) that a "mixed unix-vms file specification" means it starts as VMS
        and ends as Unix (i.e. it cannot start Unix-style and end VMS style).

Obviously, this will make vms_unix_mixed_filespec() much "bigger", possibly
slower. However, I think that vms_unix_mixed_filespec() is NOT able to handle
this correctly, without the help of the decc$...() functions. In 
particular, it
cannot know what the decc$...() functions know - the distinction 
between rooted
and unrooted logicals, the defaults (of the default directory) etc.

Consider all these cases that must be handled correctly:

A) sys$login:vimfiles/after
B) rooted_log:[a.b.c.d]vimfiles/after
C) set def [a.b.c.d]
    rooted_log:vimfiles/after (should give the same result as B)

The solution proposed above solves this, while the current solution fails in
point A.

Correction: only the latter path is not handled correctly:

sys$login:vimfiles/after

The former is fine.

This is another complex path-related problem; see also Ticket #10. The 
two are,
however, almost unrelated.

My 'runtimepath' contains paths like these:
  OBDEV:[VIM]vimfiles/after
  sys$login:vimfiles/after

These are obviously combinations of VMS-style paths (using colons and []) and
Unix-style paths (using forward-slashes).

However, VIM fails to read from these paths.

I believe these paths should work, since they are set up by default (they are
not my settings). OBDEV:[VIM] is the value of my VIM logical.

I will post my analysis of this shortly.