What we did originally in the HP-UX compat long ago was have a program called
"hpux" which essentially just did a 'chroot("/hpux")' and then executed
whatever command you gave it.  Then we populated the /hpux tree with
interesting HP-UX binaries (or just mounted an HP-UX machine there).
(this is what Berkeley has always done with "/nbsd").

This achieved the same result as I gather you want, but required explicit
action by the user.  They had to remember to type "hpux command" rather
than command or do "hpux sh" to get into an hpux environment.

We did it this way because we also wanted to be able to run HP-UX binaries
in the "native" environment.  For example, at the time (1987) we used the
HP-UX 68k C compiler tool chain as our native compiler.  Hence, we were
running an HP-UX binary but with standard BSD paths (include files and
libraries).  As I understand it (though I missed the initial messages on
this) you would not be able to do this with namei always performing the
translations.  Do you want to be able to do this?  That I don't know.

This is still how we do it today on the PA, where we use the HP-UX X
server binary.  It is a lot messier with shared libraries where we have to
put HP-UX binaries (or symlinks to), e.g. /lib/dld.sl, /lib/libc.sl, into
our standard directories.  There is also the possibility of name clashes,
e.g. if we had a BSD libc.sl.  Union mounts can take care of cleaning up
the mess, but doesn't help with the name clashes.

Do you really need an alternate namei path here?  Can't you just do an
implied chroot when you exec an emulated binary?  Are the semantics different?
Should I just shut up and go back to working on Mach? :-(