tagging API?

Hello,

On #807, one option that i did not see considered is the posibility of defining an available (if experimental) tagging API, with ForwardDiff.Tag as it's only available implementation in ForwardDiff, via an AbstractTag{F,V} supertype.

For example, one package implementing StaticTag{F,V} <: AbstractTag{F,V} (in particular, https://github.com/JuliaDiff/ForwardDiff.jl/pull/807#issuecomment-4472479160 without the fallback) could define their own static comparison mechanism, without compromising the current runtime capabilities that ForwardDiff already gives with their own Tag implementation, and erroring when there there is any ambiguity (closures of duals) instead of recurring to checking a global value.

Another example was an attempt done in #748. While the discussion on that PR was long and the PR was finally reverted, that PR inadvertly required following a currently private tagging API:

• checktag
• ≺
• replacing most hardcoded Tag constructors by an overloadable maketag method

While i agree that the current Tag mechanism is adequate for most automatic differentiation workloads, new use cases, like completely compiled evaluations, merit thinking about the current invariants baked in the package, in my opinion. In this context, the implementation of a tagging API just shifts the burden from the ForwardDiff developer to the developer of the tagging mechanism.

Start by reviewing issues #807 and #748, then inspect the existing ForwardDiff.Tag implementation and the mentioned checktag, ≺, and maketag entry points. The issue proposes an experimental AbstractTag{F,V} API, but does not define a concrete interface or acceptance criteria; done would require agreement on the public design and its invariants.