Using Lookup, for example

Lookup.getDefault().lookup(new
L.T(CatalogReader.class))

where catalogs are conventionally placed in a
designated folder

Services/XMLCatalogs/

or similar, where each file there is an instance
of CatalogReader. CatalogProvider could be
deleted, as new kinds of catalogs could simply be
placed in

Templates/Services/XMLCatalogs/

CatalogRootNode would become a
DataFolder.FolderNode with a different icon etc.
(see various such folder nodes in core for code
examples). Its new type could be replaced with a
TemplateWizard.Cookie pointing to the catalog
template area, and CatalogMounterModel etc. etc.
could be replaced with standard
TemplateWizard.Iterator implementations.
CatalogSettings could be deleted, as the folder
would handle its own storage using .settings files
etc. Listening for changes in catalogs etc. would
be replaced with a standard LookupListener idiom.

Besides possibly simplifying the xml/catalog
module and making its structure more standard, it
would improve the ability of other modules to add
catalogs; for example API Support would probably
add an instance of the NetBeans Catalog by
default, since NB developers would normally want
it mounted. This would be trivial to implement:

<folder name="Services">
    <folder name="XMLCatalogs">
        <file
name="org-netbeans-modules-apisupport-nbcat.instance">
            <attr name="instanceOf"
stringvalue="org.netbeans.modules.xml.catalog.spi.CatalogReader"/>
            <attr name="instanceClass"
stringvalue="org.netbeans.modules.xml.catalog.impl.SystemCatalogReader"/>
            <!-- also localized name & icon for
display -->
        </file>
    </folder>
</folder>

Similarly, the web/advanced module would no longer
need this ugly trick in its ModuleInstall:

public void restored() {
    // ...
   
CatalogSettings.getDefault().addCatalog(getDDCatalog());
}

which is contrary to the spirit of layers, for
example because it will cause a change to
CatalogSettings in every project without the
possibility of override.

If CatalogReader is ever added to the official
xml/api API set, it would be much less
controversial if it were kept small (just one
interface) and did not have the extra API/SPI
weight of CatalogProvider, CatalogSettings, etc.