[racket] Should we _always_ use `only-in` or `prefix-in` when `require`-ing packages?

> I explicitly mentioned this in the RacketCon talk.

Sorry, I was distracted because I was on-deck to give my talk next. :)

> PLT generally does
> not consider new exports to be backwards incompatible, even though in
> principle it is.

In general I agree with that. Certainly when I'm building things
locally, it's not a huge practical issue. I know there's a chance a
new version might introduce a collision that I need to fix. If so, I
fix it -- or if it's too painful, I avoid the new version, maybe.

The thing that struck me lately is the scenario where the user is
building it in the field. They might get newer pieces than I knew
about, last I updated my package. I wouldn't know it broke until they
told me.

If I put a package out there, I'm willing to maintain it as-needed.
But I also want to avoid unnecessary breakage and fire drill hotfixes.
 Using `only-in` or `prefix-in` is a way to leave my latest package
version out there in a form that's more durable.  Maybe that was
already obvious to others as a best-practice.  It only became obvious
to me when doing some end-user technical support. :)  So I wanted to
share that.

> I think the only-in/prefix-in idea is the right way to go, but it is
> pretty painful. There are a few ways to make it simpler. I have a
> "interface" experiment that makes it so you can define an interface to
> a module separate from its implementation:
>
> https://github.com/jeapostrophe/exp/blob/master/interface/interface-in.rkt
>
> I think that using such a system in a more integrated way throughout
> Racket is part of "Racket 2".

Well, I haven't found it excessively painful. Not even manually. (So
far. Maybe a painful case lies around the corner.)

A tool that can check `require`s generally -- including entire modules
you don't use -- could probably spit out a list of the item actually
used from a module?  Or maybe that's easier said than done.

The interface idea for the future sounds interesting, too.