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

> In my experience, using plain require and later adding 'except-in' when a service module decides to widen its interface is a much simpler approach  than pre-emptively using 'prefix-in' or 'only-in', especially if you need (almost) everything from a (possibly large) library. -- Matthias

When building locally, I feel the same way.

The problem is when my package depends on other-package, and users are
building my stuff via `raco pkg`. If other-package widens its
interface in a way that conflicts with my package, I will probably
first learn about it from a user who can't get my thing to install.
Then I need to do a fire drill to update my package. (Unless I used
only-in or prefix-in, in which case I'm probably OK.)

Actually it could be worse. If my package depends on other-package,
which in turn depends on other-other-package, and the breakage is with
the last two?  Now it's a fire drill, but even if I wanted to roll out
of bed to hot-fix it, I can't do that myself. (Unless it's understood
best-practice to use only-in or prefix-in, and other-package's author
did so.)


I understand that breakage could happen in other ways, too. I'm just
saying this is _a_ vector for backward incompatibility that might not
be obvious to everyone. Either because they weren't aware of it, at
all. Or because they're aware of the possibility, but their estimation
of the consequence is framed by building locally instead of users
building in the wild.