Maybe AbstractDifferentiation should shrink to a collection of names?

I increasingly feel like all the heavy lifting should be done by backends, and AbstractDifferentiation.jl should just define common names.

Whenever we do something that a backend does not support, or when we recode it instead of letting the package do it, we introduce correctness, readability or performance issues. Some examples:

• additional closures with type instabilities (#109, #121)
• hard-to-parse macros (#123)
• vicious tuples (#99, #53)
• no exploitation of optimized backend code (#54)

Moreover, the complexity of the package also makes it very hard to push Enzyme support over the finish line (#84), which is arguably the biggest missing feature.

@adrhill and I are working on a prototype to play with this idea:

https://github.com/gdalle/DifferentiationInterface.jl

It may or may not be merged into AbstractDifferentiation, depending on what the team here thinks. The main caveat I see is that higher order cannot be well supported with an empty shell, but for gradients and JVPs/VJPs it should be close to optimal.

Read the current AbstractDifferentiation.jl interface and compare it with the linked DifferentiationInterface.jl prototype. The issue names no specific file, test, entry point, or acceptance criterion, so the first step is to resolve the proposed scope and define what a successful backend-focused redesign would include.