I took a stab at fixing this but looks like it's not so trivial. Or rather, there's a deeper bug lurking. Turns out add_loaded_labeled_asset is just kinda broken. When you do an immediate load of an asset, it assigns the path of the asset you are nested-loading. So if you are loading asset "a.txt", and within you load "b.ron", subassets of the second asset will have a path of "b.ron#subasset1", rather than "a.txt#subasset1". This means the path "a.txt#subasset1" perpetually is in the NotLoaded state.

I think we need to propagate the path into these subassets. We treat the "root" subasset of "b.ron" as a regular subasset of "a.txt", so we need to somehow set the path of its subassets to be "a.txt".

Ok I've figured out more of the problem. Here's a diagram I came up with:

root loader tries to load "root#nested/subasset"
v
root -> nested -> subasset
          ^
nested loader finds handle for "nested#subasset" (or generates it) and stores it in nested

Once root calls add_loaded_labeled_asset, it registers all "nested" subassets as subassets of root - but now with the path "root#nested/subasset" (which is not what is stored in nested)

In essence, the handles we store in the "nested" asset (in the nested loader) correspond to a different path than "root". That means when we look up the handles of assets in "nested", those assets will never get loaded, since they were loaded as subassets of "root".

I don't understand yet how #15481 broke this. It seems to me like this problem should have been just the same in that situation...

Now I think I understand the full scope of the issue. Nested asset loading is weird...

(Also to be clear, this is all addressing that "deeper bug" I mentioned above).

The problem is that before #15481, LoadedAsset had two functions:

1. It was the type you get from LoadContext::finish for a subasset in the current loader.
2. It was the type you get from NestedLoader<StaticTyped, Immediate>::load.

This means LoadedAsset::labeled_assets could store two kinds of assets:

1. Subassets of subassets.
2. Subassets of a dependency that you did a nested load for.

#15481 (my PR) assumed we were only holding the first kind of asset. However this is a problem for the second kind of asset. The nested asset loaded the asset assuming the path was for the nested asset. That means the handles are all related to the path "nested#subasset_name". After #15481, when we merge the labeled_assets of a CompleteLoadedAsset coming from a nested load, we don't give them a new handle related to the root asset. So even though we treat it as a subasset (requiring uniqueness), we can't access it like a subasset ("root#subasset_name").

We could prevent registering nested-loaded assets as subassets, but then any handles you get from that nested load are useless. Unless we register these nested-loaded assets as such in LoadContext. This would make these nested-loaded assets no longer subassets, but correspond to their "real" counterparts. I think this is the path I am going to explore.

Nested asset loading is very weird. It's not just parsing bytes - it can load another actual asset. I think we need to take a more general look and redesign nested asset loading. I have a feeling we can consolidate a lot of the loading stuff. But I digress.

There's another issue creeping up that I'm not sure how to handle. AFAICT, nested-loading an asset path with a label is broken. Unless I'm missing something, it will give you the root asset when you requested the labeled asset. Unfortunately, we're in a bind to fix this. If we properly return the labeled asset, we won't know which subassets are relevant to that subasset (since we remove that information when we merge subassets of subassets). So any handles in that subasset can't be found, so we can't package them up into CompleteLoadedAsset, and we can't register them in the root loader. Before #15481, this was more likely to work correctly (since we could register subassets to their "parent" subasset), though it still wasn't guaranteed.

One immediate solution: we could just panic if you pass a label when doing a nested asset load. At least this would prevent erroneous requests.