Assumptions

1. The removal of _n and _s sprites
   Currently, this concept's implementation uses a mixin to SpriteSource$Output#add(ResourceLocation, Resource), which is a default method of an interface. That interface is only implemented internally so it is unlikely that the method will actually be overriden but it is a possibility.
   The larger problem with this implementation is that it does not consider custom SpriteSourceTypes. A mod could add one that loads sprites from files like "single" or "directory" but does not use the default method that Iris mixes into.

2. How PBR sprites are loaded
   Currently, this concept's implementation assumes that sprite names are of a certain format (1) and that each sprite is loaded from exactly one file (2).

   • (1) can be broken with only a resource pack. The "single" SpriteSourceType can provide an arbitrary sprite name using the "sprite" key. In this case, the sprite name might not be the sprite file source location, but Iris will assume that it is.
   • (2) can also be broken with only a resource pack. The "unstitch" SpriteSourceType can create multiple SpriteContents from one source file. In a different scenario, a custom SpriteSourceType added by a mod might not use the ResourceManager and thus none of the sprites loaded by it would have a source file.

Possible Solution Ideas

The best solution in my opinion to fix these fragile assumptions is to individually consider each SpriteSourceType. How exactly this would work will require some more thinking, but for example, if the "single" and "directory" SpriteSourceTypes are considered, then the assumption of each sprite being loaded from one file is guaranteed to be upheld and the file source location can be accurately determined. Additionally, if the "unstitch" SpriteSourceType is considered, then its implementation can be taken into account to make PBR loading work with it as well, since currently it does not.