Racket 8.0: Avoiding Accidental Public Exposure via provide (all-defined-out)

The goal is to maintain strict encapsulation of helper functions when migrating from Racket 7.0 to 8.0. In 7.0, (only-in mod id) allowed importing any top‑level binding, regardless of whether it was exported. 8.0 tightened this rule so that only identifiers explicitly exported by provide can be imported. Developers often add (provide (all-defined-out)) as a quick fix, but this unintentionally promotes internal helpers to the public API, increasing the risk of name collisions and misuse by downstream users.

There is no compile‑time warning in 8.10 when a module re‑exports an identifier that was not originally exported, leaving the decision entirely to the programmer. This lack of feedback may lead to fragile code that becomes incompatible with future releases that further tighten module semantics.

What mechanisms, if any, should Racket provide to alert authors when re‑exporting non‑originally exported identifiers? How can developers balance the convenience of (only-in) with the need to keep helper functions private without exposing them through (provide (all-defined-out))?