Our usual approach when fixing failures like this is to list missing specializations in the corresponding default.rd.xml, which should hopefully no longer be necessary once generic theories are supported in Native AOT I believe @agocke has been working on this space.

I find this cleaner and less susceptible to bugs introduced by refactoring or new additions causing later failures due to not updating the rd.xml.

Sure, but the point having a theory is being able to test individual inputs independently without success of one input dependent on the success of the previous inputs.

That's a benefit of theories, yes, and we give up on that benefit frequently for things off the golden path, such as more inputs than the system can handle, places where theories aren't conducive to the kinds of work being done, or places like here where without significant overhaul to how they're implemented they're not compatible with aot. I'd much rather give up on that minor benefit than have this fail in complicated ways when we add one more input.

It's possible the work Andy is doing won't even support generic theories. It's not exactly trivial to figure out the type information necessary to source generate the actual generic parameters to call the theory with at compile time.

I believe it's possible for it to work in principle, although it might require constraining what generic theories are allowed or adopting a new DSL. In any case, we can adopt this approach for now to unblock testing.