Issue

The USD API allows to implement a custom Asset Resolution Resolver known as a ArResolver.

Asset resolution is the process by which an asset identifier is translated into the location of a consumable resource. We use the general term "resource", though in reality parts of USD currently assume resolved assets are files. USD provides a plugin point for asset resolution, the ArResolver interface, which clients can implement to resolve assets discovered in a USD scene, using whatever logic and external inputs they require. Because USD itself always calls into the ArResolver plugin to resolve an identifier before consuming it, the plugin provides an opportunity for clients to fetch resources and make them into files for USD's consumption, so that they can work around the assumption of resource-as-file until such time as we may be able to remove it.

To benefit from Avalon's publish versioning we'd need to implement a custom resolver as USD itself allows no 'embedded urls' to be changed, thus you can't update an embedded version to the version you'd like. Instead USD does allow a custom resolver to "resolve a specific url" to a specific file on disk, as such that would also allow to load updated embedded versions.

The ArResolver interface can be customized per USD installation, allowing, for example, site-specific naming conventions to be resolved, and for dynamic versioning control to be applied. Source

Having an Avalon ArResolver would mean that paths would be set to something like:

avalon:?project=Alita&asset=characters_hero&subset=modelDefault?version=1

(The exact implementation is to be discussed)

Then as USD loads the scene it resolves the URI to a path on disk and loads it from there. In other words, the ArResolver gives you an opportunity to intercept asset paths and translate them to a path on disk.

Notes on implementing an ArResolver

C++ only: A custom resolver can only be implemented in C++

Ar does not support custom resolvers implemented in Python to avoid performance issues, especially for multi-threaded consumers. _Source_

Can't access Avalon python API: Because it's C++ only a custom resolver can not easily access Avalon's Python API. As such, it would have to do its own resolving that hopefully can trivially match Avalon's path resolving for a file on disk. Maybe it would need to use the Mongodb C++ Driver to access it directly (if it needs to touch the database).
Resolving should be heavily optimized: The code for resolving will trigger many times, for each referenced/layered/loaded USD path that triggers the resolver. As such, in a production environment and a heavy scene it could run 1000s of times. Thus queries against a database should be avoided (or if impossible, as limited as possible). For example note ALA discussing their implementation and optimization concerns.
Resolvers can have a custom Context and Scoped Cache: What we need to implement to make correct use of this I'm not sure yet, but be aware that these are recommended to read up on.
Storing resolved paths for renderfarm jobs: As Animal Logic Academy (ALA) describes they stored a file on disk with the resolved paths for render jobs on the farm. Otherwise the high amount of machines all querying the database at the same time resulted in a heavy stress on the servers. As such, it could be good to keep in mind that we might need to do something similar to ensure a high performance for machines who ultimately resolve into the same final path.
We might need to make sure the URI also defines the Project and/or Project root so that potentially we could use Library assets (from other projects) correctly, like #366

References

Some reference ArResolver implementations:

This issue relates to #477 as it's part of a USD implementation for Avalon.

getavalon / core

Implement an Avalon ArResolver for USD #478

Issue

Notes on implementing an ArResolver

References