I really don’t know how to word this better, but to me that sounds like that PR should not have been merged as it was, if “Don’t rely on undocumented, non-API Base internals” is a critical policy for your package. It is not the responsibility of Base to ensure your package is using the API correctly or doesn’t access internals it shouldn’t access.
Again, it’s absolutely fine if you decide that the function is useful to you and you want it. You do assume responsibility for your uses of it though, since there is never and has never been a stability guarantee for internal functions.
Likewise, Base cannot go around and vet every package in existence to check whether they conform to the documented API or not.
I want to make this absolutely, perfectly, 100% clear: This was not a breaking change. Just because some internal function doesn’t exist anymore or changes behavior, does not automatically force the change to be a breaking one. Breaking changes only ever relate to changes in documented API.
As I said above, it is NOT feasible for Base to go around and check every single package in existence on every single PR to Base for any potential breakage. Not only would that be a huge timesink in terms of “time until a PR to Base gets merged”, it would also constitute dealing with already broken packages and having to review them on any change to Base. This also doesn’t work for PRs to Base that require subsequent follow up PRs or require some other work from some other PR that hasn’t been merged yet, but is otherwise complete to base new PRs off of.
This is not an option and is why API as a concept is distinct from “the functions I can reach syntactically”. Since the function in question is not part of the documented API, the change was not breaking, because it did not break any existing uses of the documented API.
On top of this, every release for julia has a list of included commits, automatically generated and linked in every announcement post for that version (here’s the announcement and here’s the list of commits for 1.8-rc1). It is not feasible to write a blurb in NEWS.md or some other document for every single removed/changed/added internal function - that list would very quickly become much too large to be practical to scan or read through, when a single CI run of a package in the new version can already detect that change perfectly fine and report it to the people most interested in that specific change: the maintainers of the package.
Also, as @Tamas_Papp mentions, PkgEval is already run for every package in existence before a release and if your package is found to break due to a change in API, you will get notified/the change will be reverted (depending on severity). In this case, the package is relying on an internal, undocumented function that is not part of the julia Base API, so the break is on the package maintainers to fix for relying on the function in the first place.