Documentation attributes are coming in OTP-27, and we can start using them to express internal exports.
We can always add new ways to do this, but we need to be careful to do it in a way that Erlang/OTP can be maintained by a small team.
At the moment, we believe that this is a simple way to achieve that.
That said, thank you for your EEP contribution, even if this time around we could not integrate it in Erlang/OTP.
We are always looking forward to reading community EEPs. Keep them coming! 
Under this EEP, whether an exported function is internal or not is a documentation detail as there is nothing stopping anyone from calling it anyway. Had the EEP enforced -internal_export then things would be different, but as things are it is nothing more than documentation.
In the end it doesn’t matter whether a tool reports that you’re trying to call an undocumented function in library X from library Y, or an internally exported function in library X from library Y. The PR that implements this functionality in xref can be changed to use -doc attributes instead.
I find it difficult to accept that a new user is experienced enough to be worried that people will use internal functionality, yet simultaneously not experienced enough to write documentation for libraries they expect other people to use.
I believe it’s more likely that they will notice that their internal functions show up in the documentation, at which point they will look for ways to hide it and soon find -doc hidden.
N: But i’n not currently even writing documentation
N: xref should be aware of documentation?
N: how many of these things are hidden in the language/ecosystem ?? (that i can not easily find)
xref doesn’t provide this functionality at all right now, and once it does with the PR you folks kindly sent in, the feature could be documented as (and of course named after) warning about calls to undocumented functions, at which point -doc hidden. becomes natural.