The mechanism for registering a resource alias is rather cumbersome, as it support aliases that reference an arbitrary location in the model
Renaming a resource path is the simplest (and, I suspect, most common) use case for aliases, where the alias and target have the same parent, e.g.
/subsystem=test/foo=* -> /subsystem=test/bar=*
or
/subsystem=test/foo=bar -> /subsystem=test/baz=qux.

Currently, alias registration typically looks something like:

PathElement path = ...;
PathElement legacyPath = ...;
ResourceDefinition definition = ResourceDefinition.builder(ResourceRegistration.of(path), resolver)).build();
ManagementResourceRegistration registration = parent.registerSubModel(definition);
parent.registerAlias(legacyPath, new AliasEntry(registration) {
    @Override
    public PathAddress convertToTargetAddress(PathAddress address, AliasContext context) {
        // ...
    }
});

If the alias and target are siblings, i.e. have the same parent, the AliasEntry implementation will be the same regardless of alias/target, and thus we can simplify the last line of the above code as:

// Register alternate path for this resource
registration.registerAlias(legacyPath);

For simple aliases, it is more natural to register the alias directly with the target MRR rather than its parent.