The general rule is that release management is agnostic to the type of software it manages, hence there should not make any difference releasing a metaverse or a smaller mobile app or even a hardvare for that matter. So I would not focus on differences in the methodology or the work-flow, but the type of releases, or should I say release classes, that make metaverse releases special.
A metaverse stack has several layers...
For a casual user a metaverse software is usually a mobile app or sometimes a desktop version of it. But behind and within there could be many different parts/layers that can/should or cannot/should not move paralell or hand-in-hand or sequentially. Like the regions the user arrives to, or individual assets, furniture items in a specific region, etc. So beyond or below the app there are contents and infrastructure and admin dashboards, etc. From release management point of view it is worthy of taking the effort and define them and see their release related releationship to each other. These decisions of inter-dependencies that make certain changes of different stack layers to be items of the same release, so these decisions must always be done by the architects of the stack, a release manager should only facilitate these decisions, never make them.
App-layer (App Release)
The metaverse apps are ususally called viewers and their relationship to the actual content is very similar to a browser's relationship to domain names or webpages. So in principle the app layer can be released on its own. These are the normal App Releases. The only part of the stack that always needs architectural investigation is the admin panel or dashboard. As certain release items (changes/features) of an app could have some prerequisites on the Admin panel/dashboard side. If so then an app release must happen together with a Dashboard release, or should we say we must have a release that has release items from our app and from our dashboard so the changes must be delivered at the same time to the two different layers of our stack.
Admin-panel-layer (Dashboard Release)
Worlds and regions of worlds in the metaverse require certain admin functions (like managing users, region accesses, the availability certain features, etc.). This management rarely happens in the app itself as it needs higher access to user databases, content servers etc. So most dashboards are web-based which makes them semi-independent from the app from the basic release point of view. These are the ususal Dashboard releases of our days.
Content-layer (Content Release)
Most of us visit metaverses for their content, so our content layer is probably the most valueable part of a metaverse stack. As in our analogy of 'browser vs. website' Content Releases are usually independent of app releases. Usually, but not always, because contents are in constant competition and certain content functions (like animations, cross-platform content sharing, etc.) require ever-newer app functions to support them. Like the priciest/fenciest avatar outfits are worth nothing if a viewer cannot display them properly. So content layer and content demand items are probably the main driving force of app and admin features. This can also force different changes from different stack layers into one release.
Infra-layer (Infra Release)
Infrastructure changes can be and usually are independent from our other release types, but not always. If a content release item demands a certain version (upgrade) of our base softwares or engines then infra changes and higher layers are tied together. So in the case of such changes they are delivered in the same release.
Honorable mentions:
SDK release
Hotfix release
Security release
So as we saw metaverse release managment needs to create different release types and understand deeply their relationship to each other to be able to create the most effective release scoping and ensure the shortest Time-to-Market release cycles.