Greetings Flintlock,
I thought of several opportunities related to unit movement that could be quite valuable to modders. I expect the first several suggestions would be simple fixes. The last suggestion would be significantly more involved, but might open up many modding opportunities relative to the amount of coding work required. Of course, I completely understand if you never pursue these ideas - just thought I'd present them in case they pique your interest (or the interest of some future modder). Thank you for the work you're already doing!
All pictures are from the Quintillus scenario editor.
-----------------------------------------------
Smaller fixes:
1. Allow teleportation of "immobile" units. There's no reason for applying the teleport ability to an immobile unit unless teleportation is supposed to be an exception to the immobility.
2. As an alternative to 1 (or in addition), the scenario editor allows for scenario designers to remove the "go to" action from units. This would hypothetically be another way to make a unit immobile in certain respects. However, if "go to" is unchecked, the AI can still move the unit freely, and humans can still move the unit via pressing the arrow keys.
3. [Not exactly a fix:] Allow any (land?) unit to retreat if faster than the unit it is fighting. Right now a fast unit can only retreat if attacking a movement 1 unit.
4. Fix the game crash when someone (including an AI) attempts to unload an immobile unit from a ship onto land (and from a land carrier onto land?).
-----------------------------------------------
The Big Addition:
I have thought of a way to make terrain have unit stack size limits while leaving older scenarios' gameplay unchanged. Stack limits would open up many, many tactical options for scenario design.
Give all terrain a base unit "capacity" of 3600 (or some other large number - more on why I mention 3600 below) divided by the movement cost of the terrain.
Give each unit a "size" parameter via the unused scenario parameter which defaults to 0 for all units:
Require that a unit cannot move to a terrain square unless there is enough room. That is, the unit can only enter a square if the size of the unit plus the sum of the sizes of the units already on the square is less than or equal to the capacity of the square.
Because the parameter is zero by default, all existing scenarios' behavior will be unchanged. However, if someone wants to implement limited unit stack sizes, they can do so! Further, the option to customize each unit's size allows for many complex combinations and possibilities.
Because the size parameter can be set to negative values, you can even have "supply chain" units which increase the capacity of a square!
Here are some details that would likely need to be addressed if this change were to occur:
0. Units need to be able to attack squares that are full.
1. Ships should probably have a distinct space usage from air and land units.
2. If cities have a unit capacity limit, then perhaps city production should wait to produce a unit until there's space (like with settlers and population).
3. If such a limit applies to citiies, perhaps it should also be applied to buildings which produce units.
4. Perhaps city unit capacity can be based on city size?
5. Movement restrictions would need to be coded for all the kinds of movement - airdrop, teleport, rebase, ship-unload, land-carrier-unload, etc.
6. The reason I suggested 3600 for the basic terrain capacity is that it is divisible by many useful numbers. Thus, the scenario designer can easily assign unit sizes to partition the capacity space. The prime factors of 3600 are 2, 2, 2, 2, 3, 3, 5, 5. This means 2, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, ... and many many more numbers divide 3600 cleanly. For example: Want 12 units per standard tile, 6 per hill and 4 per mountain? Then assign units sizes of 3600 / 12 = 300.
7. Consider having the "unit X ignores movement cost of terrain Y" option in the scenario editor also make the unit not count toward the size constraint on squares of that particular terrain type. Not sure if that would be a good addition or not.
8. Consider not making a square's capacity based on the terrain's movement cost and instead having a fixed capacity (e.g. 3600) for all terrain types. I personally think the extra constraints would enhance scenario design options, but maybe not...
9. The AI's pathfinding code might get much more complicated?