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.

-

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).

-

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.

-

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...

-