Looks like the Rarity entry in Blizzard's UI is no longer added immediately, meaning /rarity must first be used to load the addon. This might be a side effect of moving to the new LoadOnDemand system (see #752).

Should be easy to fix, but I haven't looked into it yet.

Correct. Using the minimap button to open the settings also works.

Right. I guess it would be a little unfortunate to leave this unresolved, but I don't see a way of adding the category without loading the Options module (separate addon) at a glance. It might be possible to create a "placeholder" category with a button that says "Load Options module", as some other addons do. That would certainly take some work to implement and test, though.

Since I'm out of time, I'll create a tagged release anyway and hope there won't be too many bug reports 🤷‍♂️

I have a solution in principle, but it's just a quick prototype for now. The issue is, effectively:

• The Rarity_Options module (addon) have to be enabled so that its UI panels are created and registered with AceConfig
• Loading the options immediately would work (players can see the menu), but it's slow and not a sane default
• Loading the options on demand, be it via slash command/LDB/mini map button/addon compartment also registers the menu
• Rarity needs to create the AceConfig registry entries without also creating the entire widget tree, as early as possible
• The full UI can take significant time to create, so it should be deferred until /rarity is typed or it's manually opened

It's possible to do this by defining a generator for the options table, which is called when the hierarchy need to be created:

	function R:OnEnable()
		self:DoEnable()
		-- The Options module is disabled to reduce memory usage and loading time
		-- However, players can only see the menu entry once AceConfig has registered it
		-- Workaround: Register a generator (function) that creates the UI only when needed
		LibStub("AceConfig-3.0"):RegisterOptionsTable("Rarity", R.LazyLoadOptions)
		R.optionsFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("Rarity", "Rarity")

		-- Similar approach for the other panels ...

function Rarity:LazyLoadOptions()
	R:Debug("LazyLoadOptions")
	if type(R.options) == "table" then
		return R.options -- Options were previously generated (fast path; upfront cost was already paid)
	end

	R:Debug("LazyLoadOptions requires LoadAddon (this may take some time)")
	Rarity.Profiling:StartTimer("RarityOptions: LoadAddon")
	LoadAddOn("Rarity_Options")
	Rarity.Profiling:EndTimer("RarityOptions: LoadAddon")
	assert(type(R.options) == "table", "LazyLoadOptions called LoadAddon but it failed - check for script errors?")

	return R.options
end

This seems to work well: The "open to settings" cost is paid when Blizzard's UI is accessed, and the "generate UI" cost on click.
The loading time is only significant on retail (larger options table), but it increases with the number of installed addons:

• Retail: Options takes 34 MB of memory, opening took 200 ms, opening Blizz UI took 900ms - lots of addons
• Cataclysm Classic: Harder to say, no addon metrics API available - collectgarbage("count") suggests 3 MB; 50 ms load
• Classic Era: Load time isn't worth mentioning because the size of the database is pretty much negligible - no addons

(Some care needs to be taken to create the entire tree in one step, with all of its submenus, to avoid unexpected behavior)