To add to what Dave said, quick brain dump, hopefully not too unreadable...
Most important for me, I'd like to be able to define multiple (what I'll call for now) repositories (like Debian "apt"). So that I can have, for example, a repository for core official blessed Racket components, one for contributed (what's currently PLaneT), and one for packages internal to an organization or project. (Note that Debian has a mess of features for managing using multiple repositories, which most people don't know about, and which aren't necessarily reliable because not all tools respect the policy and some of the policy is kludgey anyway.)
Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories. Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome.
It would be nice to be able to set policy in one place, for what packages and versions may be pulled from the non-internal repositories for a particular large system. For example, since there are cost/benefit tradeoffs, to each third-party package we use, including security and quality, a project team might want to declare "this project may only use package foo version 1.3 and package bar versions 2.1-2.3 from the contributed repository, and no others at this time". (I have started to partly approximate this in one large system by having an intermediary "planet-*.ss" for each permitted require from PLaneT, but that alone does not prevent programmers from adding requires directly from PLaneT.)
Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made.
When pulling from the contrib repository, we sometimes also need some confidence that version 1.3 today is the same code as when we vetted version 1.3 six months ago. Maybe that's satisfied by us pulling from a transparent copy we made at the time (and not accidentally pulling from the repository). Or maybe we copy the code and permanently disentangle it from PLaneT, which is expensive and stodgy. Or maybe we trust the PLaneT server and our link to it not to be compromised, which we can for some applications but certainly not for all. Or something else.
Separately, breaking up the monolithic Racket distribution into PLaneT-ish packages has some appeal to me, though it is not as important to me as the things above. This appeal is partly pragmatic, such as an assumption that the factoring into modules will have a side effect of fitting Racket onto smaller storage, and the (rare, in my case) desire to pull some released improvement into a production system that is mostly frozen at an earlier Racket version. The other part of appeal, at least to me, is aesthetic, in the same way that a self-hosting language implementation is considered elegant, and we might expect practical benefits to someday fall out of that (or perhaps they don't). If numerous PLaneT requests were actually used for the normal way of installing core, however, either all-at-once or on-demand, that could result in a poorer install-time or run-time experience than currently. So I think a monolithic tarball/zip/etc/dmg/etc would still be a good idea, even if internally it's broken up into packages.
If breaking up core into packages, and still offering a monolithic distribution tarball, whatever policy affordances the implementation of that monolithic packaging adds to PLaneT caches might also be applicable to purposes mentioned above, like selectively using a few contrib packages and being confident they don't change.
I'm guessing that most of this is relevant only to people doing large development, and who are engineering-inclined and looking to safe effort and stress. However, one does not necessarily need these things to do large development successfully in Racket and using contributed PLaneT packages.
-- http://www.neilvandyke.org/ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
