Better control over what nests/worms are built on expansion

[Quorken]

I am requesting finer-grained/more intuitive control over what structures are built upon expansion, as was recommended in How to control what bases/worms are placed on base expansion?.

Requests:

#1
At minimum, I would like an expansionWeight in EnemySpawnerPrototype and TurretPrototype that determines the relative chance a given structure will be built by an expansion party.

#2
I would also like it if the on_biter_base_built event also gave the prototype name of the unit "consumed" to build a nest. This would allow mods to, say, make only desert biters able to build desert nests & worms.
So if you want to make the structures built depend on the unit "consumed", instead of capturing on_build_base_arrived, and writing your own logic to build the nest (iterating over the UnitGroup's members, spreading the structure creation over several seconds, etc.), you could instead leverage the existing on_biter_base_built event - meaning you can leverage the engine's existing logic for base construction. So there would be a lower risk of bugs (aside from biters, that is).

#3
UnitPrototype can specify a favoredStructures array, a list of spawners/turrets they will favor building upon expansion, only building other spawners/turrets if no favored structure is valid at the expansion location.
* Note: What happens in the base game if no enemy structures can be built at an expansion party's location - say a mod sets the collision masks so they can't build the nests there? Hopefully it handles it more gracefully than a crash.
Would allow relatively simple "typing" logic, without splitting units into separate forces or writing custom runtime logic.

#4
Add an on_about_to_build_base event, which provides the unit to be sacrificed, and the prototype name of the structure to be built. If the unit is destroyed during the event handling, it will prevent the base from being built. If there are multiple handlers, they would still receive the event, even if the entity is destroyed (unless it's feasible for you to "short-circuit" this, terminating the event handling early if the entity is destroyed), so any handlers would need to check if the unit entity is still valid.
The main advantage of this is that it avoids creating entities unnecessarily (compared to handling on_biter_base_built, and replacing the structure that was built), both avoiding a bit of overhead, and means other mods that handle on_biter_base_built don't do whatever they do with a structure that's about to be replaced.

#5
UnitPrototype has an expansion_expression field, which holds a NoiseExpression that returns the prototype name that should be created when expanding. Would take (at minimum) the following arguments: x, y, evolution-factor, random-value, where random-value is simply a random value generated by math.random(), so the expression's result can depend on the runtime rng (since this is at runtime, not at map generation).
Or maybe at runtime, you could define a force-specific expansion-expression, which works similarly, but also takes a consumed-unit-name argument, which is the prototype name of what unit is being consumed to build a base.
Means you could encode your expansion logic as a noise expression executed by the game engine, which (might?) be more performant than the same logic written in Lua, in control.lua.

#6
Alternatively, you could have a runtime setting for a force, generate_expansion_request_event_instead, which, when true, means that when a force's expansion party attempts to build a nest/worm, it would "consume" the unit (as it normally does), but instead generate a custom_expansion_request event. Handlers for that event would receive the prototype name of the unit that was "consumed".
tl;dr - you can, at runtime, tell a force to generate a special event each time it attempts to build a structure on expansion, instead of building a structure.
This would also make it very clear that a mod is using custom logic for a given force, potentially making it easier for mods to avoid stepping on each others' toes.

Favored ones are #1, #2, & #6, both because I assume they would be the simplest to execute, and because they would still accomplish what I am aiming for - they would still require a fair bit of scripting depending on the mod's logic, but would make it more streamlined and intuitive.