While posting in the Newtonian thread I had a wild idea:
Make the cost of a drive design (both jump and non-jump) go like sqrt(size), rather than size^2 (jump IIRC) or size^1 (non-jump, e.g. military, fighter, missile etc.).
The idea here is that an original design driver for Aurora was to discourage swarms and encourage large multi-role designs. That didn't work out, mainly (IMNSHO) because of linearity in design and production cost - "splitting" a ship design in two results in two smaller ships with the same total mass, cost, and performance. This penalizes multi-role ships because the unsplit ship will only be able to use one type of system (survey vs. military vs. jump vs. ...) at a time - it can only be at one place to do perform these roles at any particular time. Jump drive cost makes this even worse - large drives (ships) are discouraged and small drives (ships) are encouraged. Armor cost was intended to help with this, (it will go like size^(2/3)) but my experience is that the effect isn't really strong enough to notice in practice.
If the cost of propelling a single ship vs. two half-ships went signficantly down, then there would be a strong driver to offset the disadvantage of having "dead mass" on a multi-role ship.
Note that if applied to missiles, this helps to solve the "sandblasting with AMM is more efficient than big missiles" problem - 1xStr-4 missile is less expensive than 4xStr-1.
I realize this is a major disruption, and you probably won't have time to do it due to the work on Newtonian Aurora. OTOH, I don't think it would "wreck" the game mechanics, since the overall combat systems would remain the same - it would simply skew how the systems are lumped together (one big ship or several small ones). The only mechanics difficulty I see would be to decide the size at which to match the new costs with the old cost, i.e. what are "Mult" and "RefSize" in Mult*sqrt(Size/RefSize) - from this point of view it is very similar to the sensor range equation change. OTOH, I think it has a lot of up-side potential.
John