What exactly is the recommended way of handling a base for a subgame?
There is no universal recommendation, so I just give my own opinion:
If you want to make a subgame from scratch, I would recommend to see mods as modules. Roughly one functionality per mod. I promise you this will ease your life very much.
Also, take your time to look around for mods which do what you need before programming your own mods. Look for frameworks before writing your own. Here's a list:
http://dev.minetest.net/Mod_interoperabilityMaybe I should write a list of mods which almost all subgames would “want” to have sooner or later. Like a mod which adds the player model which is not called “default”:
viewtopic.php?f=11&t=10349&hilit=playermodelMinetest Game's approach is to make a very bloated mod called “default” on which many mods depend. It's bloated because it contains way too many nodes, items, player model, HUD defintions, ABMs, biomes and whatnot. IMO this is not the best approach since if you only need a node from default you have to pull in Everything And The Kitchen Sink®. But it is this way now and I don't think Minetest Game will change this in the long run. When working with Minetest Game or one of its forks, we have to live with that.
Do people tend to rely on default for maximum mod compatibility?
No. Mods only depend on mods because they require something from that other mod. This is the only reason for dependencies. Note that any additional dependency is
reducing compability, so you generally want to keep dependencies low.
In fact, default is just a mod like any other, there is nothing special about it. Default is a mod from Minetest Game which contains a lot of basic stuff like node definitions, ABMs, even the player model, and more. Some mods depend on default, but you do NOT need to depend on it if you don't need anything provided by this mod.
In general, mod developers should be encouraged to add as few dependencies as neccessary and try to make the remaining dependencies optional, if possible. And this includes dependency on the default mod. It is possible for mods to don't depend on anything, not even default. One example is a mod which only adds a few chat commands.
I argue that a hard dependency on default is rarely neccessary. Many mods depend on default only for adding crafts. But all dependencies which are only added because of crafts can always transformed into optional dependencies. If default is there, add the craft, if it is not there, add no craft (you still have the item definition).
Do they alter default a lot and have the suvgame just use those names internally for mods?
Again, it depends. For subgames which have been forked from Minetest Game, they usually tend to alter the default mod, sometimes just a bit, sometimes more.
Luckily, most Minetest Game forks tend to keep the core nodes and items and I am not yet aware of compability issues with other subgame. I think compability issues depend more or less on the subgame itself. Ask the subgame author for help.
For mod developers my recommendation is that whenever you depend on default you should specify from which subgame. As an user, it is generally safe to assume that “default” means “default from Minetest Game” if not specified otherwise.
My recommendation for subgame authors who create Minetest Game forks is to avoid removing default stuff for compability, but if they plan to heavily modify default or any other of the core mods beyond recognition, it might be better to rename the mod for clarity.
Another strategy might be to try to avoid modifying default and instead put your additions (e.g. new nodes) into a new mod instead.
But I also opine that compability should not always stand in the way of innovation. If you want to make a truly innovative subgame which will be incompatible with most default-depending mods, well, go for it. Maybe one day other mods will appear which depend on your subgame mods specifically. But I would strongly recommend to use more unique / different mod names to reflect the differences; this will also be important for dependency management.
How far does it go - Replacing dirt and stone? Replacing ores? Disabling the base biomes?
Theoretically, all of the above, and more. Some subgame modify default just a little bit, other subgames modify it more heavily. Subgame authors are free to do anything, including ignoring all conventions whatsoever. In practice, I haven't seen a Minetest Game fork which replaces dirt or stone but it would certainly be a valid use case. Adding different biomes is common. Ores are usually just added upon and not replaced, probably since the default ores are often desired. But there's no guarantee. It is important to keep in mind that there is no “subgame standard” or anything like that.
what is the norm for how much of default one overwrites eventually, assuming the type of subgame is a standard survival/creative rather than a super specific type?
There is no norm.
I think overwriting a few nodes should be safe, but removing nodes could be dangerous unless compability is not a goal (in which case I would recommend changing the names of the “offending” mods).