[plt-scheme] On PLaneT packages and compatible upgrades

I'm not a big fan of this proposal --- programmer-run wizards to 
generate wrappers strike me as a red flag. Here's a counterproposal that 
seems simpler to me:

1. Adding exports to a program remains a compatible upgrade. When a 
package author submits an upgraded package, the PLaneT server 
automatically extracts an "interface file" that contains the package's 
directory structure, and for each Scheme module in that directory 
structure its list of provided names. It checks this interface file 
against the interface file for the old version of the package and makes 
sure that the new one is a proper superset of the old (i.e. it has all 
the files and directories the old one had, and for each module the new 
version provides a superset of the names the old one provided).

2. When mzscheme encounters a
   (require (planet "file.ss" ("owner" "pkg.plt" maj min)))
for the first time, it fetches the interface file for ("owner" "pkg.plt" 
maj min) [or more generally the smallest number that the package 
specifier could match] from the PLaneT server. Then it downloads and 
installs some matching package as normal. However, when the loading is 
complete, it only binds the names listed for the file in the interface 
file --- even if the loaded module provides `foo', the client doesn't 
have `foo' bound unless `foo' is in the interface for the package the 
client thought it was receiving.

What I like about this proposal is that both package authors and package 
consumers can basically ignore it and things will work the same way they 
work right now, but with Richard's bug ruled out. No special tools 
needed, no separating anything out into interface versus implementation 
files, no requiring major version shifts just to provide an extra 
function, but this problem is ruled out behind the scenes. Generally I 
want to keep PLaneT as lightweight as possible for both package 
producers and package producers, so I favor an approach that works 
automatically in good cases over one that doesn't.

A somewhat nice side benefit is that I could allow "power users" to 
write their own interface files and use those instead of the 
automatically-generated ones.  This would let a programmer separate out 
a package's interface from its implementation in a nicer way than just 
creating a directory called "private" and hoping nobody starts relying 
on individual files in there.

Thoughts?

-jacob