[racket-dev] new package system collections and conflicts

I think this "what's the matter with conflicts, and an arbitrary package 
putting things wherever it wants, and not having a notion of 
non-backward-compatibility" is similar to "what's the matter with using 
eval for everything" or "what's the matter with defmacro" or "what's the 
big deal about having subroutines in a language".

The questioner's position works for them, some other person thinks it's 
a very bad idea, and you can trot out hypothetical scenarios and 
anecdotes, but -- since it can be argued to reduce to pragmatic 
tradeoffs involving unknowns -- you can't (at least I can't) persuade 
someone who thinks they know better.

How about we just say that the module system was originally designed as 
something that core Racket developers would like to use, having a low 
friction to moving an individual core developer's side projects into the 
tidy-looking core, or to doing other kinds of shifting they would like 
to do in core Racket?  Without an acknowledgement that not all 
third-party package developers will be working like that, nor that 
everyone wants to make the substantial compromises to facilitate that 
low friction.

For third-party developers like me, I can layer something to work around 
some of the drawbacks, and, pragmatically, that's what I'll have to do.

Neil V.