In article <Pine.GSO.3.96.971208102330.9846B-100000@numenor.turner.com> you write:
> want the new semantics to muddying the existing interface...  What
> happens if I have a gif named `ls' in my path?

Indeed. For exec()-as-document-loader, you either have to always
specify the full path (not very user friendly... and isn't it easier to
type "open foo" rather than "/some/long/path/foo" anyway?), or you have
to have "." in your path. There are probably other security
considerations as well. Putting it in userland, either in an open
program or in the shell, allows for greater configurability and makes it
easier to make it secure.

I do think extending the exec interpreter system to handle, eg, java and
other things that are actually programs, but which can't be tagged with
#! and an interpreter name, is a good idea.

AmigaOS 2.0 and later had a system where typeing a directory name would
cd to it.  You can think of this as a really trivial version of the
document-opener idea -- associating "cd" with a directory instead of
"xv" with a gif.  I initially thought it was a good idea, but after a
while, I came to dislike that feature.  I'd end up doing things like
(substituting a Unix example here) being in /usr/src/usr.bin.  I type
"make", and nothing (apparently) happens.  Type "make" again, and make
gets built (because I'm now in /usr/src/usr.bin/make).  That kind of
thing.