If I understand your problem, you wish to treat an archive file as if it 
was a directory.  Thus, in the ideal situation, you could do the following:

	cat hello.zip/hello.c
	gcc hello.zip/hello.c -o hello
	etc..


Rather than complicate matters with a second tree, use FUSE with an 
explicit directory.  For example, ~/expand could be your shadow, thus to 
compile hello.c from ~/hello.zip:

	gcc ~/expand/hello.zip^/hello.c -o hello


I think no kernel change would be required.

I'm not keen on the caret.  One of the early claims made in 

The claim is wrong.  UNIX systems have traditionally allowed the 
superuser to create hard links to directories.  See link(2) for 2.10BSD 
<http://www.freebsd.org/cgi/man.cgi?query=link&sektion=2&manpath=2.10+BSD>.  
Having got that wrong throws doubt on the argument; perhaps a path can 
simultaneously be a file and a directory.
-

[ message continues ]

Learn to read.  Linux has never allowed that.  Most of the Unix systems
do not allow that.  Original _did_ allow that, but at the cost of very
easily triggered fs corruption (and it didn't have things like rename(2) -
it _did_ have userland implementation, of course, in suid-root mv(1),
but that sucker had been extremely racy and could be easily used to
screw filesystem to hell and back; adding rename(2) to the set of primitives
combined with multiple links to directories leads to very nasty issues on
_any_ system).
-

[ message continues ]

I did read the claim and it is ambiguous, in that it can reasonably be 
read to mean that most UNIX systems never allowed such links, which is 
wrong.  All UNIX systems allowed it until relatively recently.
-

[ message continues ]

FVO"relatively recently" exceeding a decade and half.  In any case,
it's _trivial_ to get fs corruption on any system with such links -
play with rename() races a bit and you'll get it.  And yes, it does
include 4.4BSD and quite a chunk of even later history.

Anyway, you are quite welcome to propose a sane locking scheme capable
of dealing with that mess.

As for the posted patch, AFAICS it's FUBAR in handling of .. in such
directories.  Moreover, how are you going to keep that shadow tree
in sync with the main one if somebody starts doing renames in the
latter?  Or mount --move, or...
-

[ message continues ]