cc @cushon

I am interested in understanding more about the use-case. Do you want to use this just to clean up reduced classpath fallbacks, or for all of your builds? What has your experience been trying to fix these, I'm curious how often it came up, and what approach you took to fixing them? Did you generally just add additional deps?

Some notes:

Some of the same issues as #16426 (comment) apply to preventing fallbacks from happen, although they'd be rarer than with the direct-deps-only approach discussed in the other issue.

Fallback can happen for reasons like the compiler needing a transitively referenced symbol in an overload of a method when doing overload resolution. If the dependency changes the set of overloads, that could affect fallback. It can also change between compiler versions. Making it an error could be fragile.

There isn't always a good fix. Something it's possible to just add deps, but other times the compiler needs to load a symbol that's a private implementation detail of a dependency, and adding a dep would require relaxing build visibility.

It's also in tension with strict deps, since it requires adding additional dependencies that aren't directly referenced and wouldn't otherwise needed, and could become unused in the future. It's hard for other dependency management tools to reason about, since there's no direct reference to types that the additional dependencies are being added for.

[There's some overlap with internal bug b/124334239]

Initially we want to use it to just clean reduced classpath fallbacks. But may enable it by default at some point, so all checked in source is clean of fallbacks.

A few fallbacks are introduced every month. We notice them by the duplicate build actions they generate, and fix them periodically by running locally a patched bazel version that has the change in the PR. Almost all of the errors are missing classes that are solved by adding a dependency.