Ideally, modularity would be configured during asset creation. Like how Godot already allows Blender naming to do some stuff like this (even empties into joints/wheels) on import.
For basic use, I assume some of it could be done with an import script to split one scene into multiple variants based on the node tree (and names) with some simple logic/keywords. Likely makes even more sense with component-based code and using the same handling for editing code parameters.
For more advanced capability (particularly up to a character/vehicle editor) I assume it'd involve an add-on as well. At least it'd need a really solid editor script to handle offsets, symmetry/flipping (optionally, more inputs), scaling or other parameters. Something where you could easily create a new variation via a node or function call.
The ultimate form of this would be something that uses a flexible connector system, to the point you could probably assemble characters from 3D-printed parts if not a small scene.
I have explored multiple options. I know gridmap* could likely handle some of this (smaller grid for static objects, maybe other tricks for semi-static entities), I've been working on a custom shader with parameters to help with dynamic stuff (csg/textmesh color, color replacement for effects like emission or animation).
I assume things like Cyclops (level editor) or SDF modeling (and animations) could be used for an in-engine workflow. Though I am already having freezing/crashing (including some data loss) when editing things with shaders/lighting (4.4.1) so I have not tried those yet.
Also on a more basic level, I assume some rigging can be done just with node visibility and animations (+state?) though I haven't tried Blender animation yet.
* though from what I've seen, it seems like it's missing ways to properly configure bigger cell sizes easily. Sort of necessitating multiple grids (even in addition to walls vs decoration) or having cells that can overlap if you don't place them properly. I assume having multiple grids also does not calculate free grid spaces either (unless you mix grid and non-grid to use the new raycast placement).
I make the models in Blender. Animation itself could be done in either, but a mix of the two probably makes more sense (Blender for character animations, in-engine for more dynamic/combined stuff or scenes etc.).
Blender-only would probably be fine if you can export to Blender Game Engine but I'm not sure it's really a thing anymore. Godot has exports for multiple platforms (also obviously, interactivity). Though anything that could render a scene could work, Raylib or other frameworks/engines.
Not quite. The major point is that it's being rendered on the user's computer as-needed rather than the rasterized result being loaded for every pixel on the screen for every frame. The data difference can be huge, particularly as the frames/animations add up.
The most "real" implementation also allows zooming and transformations whereas something like a runtime-rasterized SVG might have ugly pixellation if you do that (haven't tested Godot's new SVG oversampling) or even just from bezier conversion with too few points. So I prefer real minimal polygons over rasterized-solution SVGs.
The 3D version of this isn't even anything exotic. It's just a 3D game without textures, using old techniques that actually still have some support thanks to being in the 3D formats. It's an aesthetic choice that is also an optimization.