I’ve a few other examples as well:
Afaik @kip was aware he was using private API, but the issue is that there’s no proper incentive to speak to the maintainer to make it public vs. just using the private api as is – at least not yet. Private API in elixir (e.g. mix) is especially problematic because of the rather fixed release cycle. The goal of this proposal is to my understanding to force (or at least promote) the work/discussion of such cases to happen at an earlier stage – at the place where someone want’s to use a private api opposed to when the dependency (elixir, plug, ecto, …) finally updates and breaks things.
Even if the private API could just be made public a few month down the line a package could at least depend on the exact version, where it’s still private, call the private API and make a note to release a new version using any updated public API when it’s released. Anybody updating before the new release would get a warning that the package does not work with e.g. elixir 1.X yet. Not perfect, as the private API could still break before the next release, but at least both parties are aware of the issues and when it’s to be properly resolved.
