Well, thoughts about reduction of micromanagement nightmare rose up to this huge "policy" set of suggestions.
First of all I'll try to enumerate the most appreciable (for me) elements of micromanagement workload in Aurora:
I. Pick-and-place repetitions with ships and loads, commanders and teams. Choosing the best from a pool can be captivating, but if you must repeatedly transpose one for another - it's disheartening only.
II. Memorizing and distributioning of strictly locally separated resources. Mineral deficits, for example. Or each colony research project progress.
III. Adjustments of mass, time or cost linkups. Men in bulk can enjoy playing with distance and velocity linkups (we are natural pursuing hunters after all), but not with mass, time or cost.
So, some possible solutions:
1. Rising mass-drivers role to an intersystem net.
Very serious part of micromanagement is an ordinary boring shipping operations. So, there is obvious need to move this workload from ships to mass-drivers. To do this, we have 3 changes with some variants of implementation:
1.1a) JP will became a small system body (maybe with its our orbit, if we have a will not to produce exceptions of the common rule).
1.1b) New type of ship or civilian colony: terminal base, that can be stationed at JP and have a mass drivers battery.
1.2) New rule of cargo packet behaviour: being flung in a jump gate, it will have to do a standart jump and: a) land at JP body; or b) caught by terminal station.
1.3) Any or most of cargo (not only mineral packet) can be packed and flung by mass-driver. Including colonists, crews, persons and teems (can be fully automated!)
1.4) Mass-driver packet can be shot at the rote (I don't know if there is possible now, but with this rising of role it will be mandatory).
1.5) (optional, but very desired) Mass driver tech level.
1.5a) New branch of research: mass-driver fling velocity.
1.5b) Linkage of mass-driver fling velocity to railgun or gauss launch velocity tech (I don't like this variant, but it can be simpler, then new tech).
As a result, we will have stable-route ordinary mass transit net (some analog of railroads and highways of land transport) instead of ordinary shipping micromanagement.
It isn't a replacement of ship-based core of game! As before, we will have a mandatory need of military ships, surveyors, auxiliary ships (tankers, colliers, tugs, jump tenders, gate builders, terraformers, etc.), and we will have a possibility even to preserve some types of civilian ships, such as luxury liners and orbital harvesters at least (but with an 1.1b variant it will be no need of sending tankers to milk those harvesters, that is another very good lowering of micromanagement workload).
Point 1.4 is a guarantee, that war in communications will preserve as possible and worthwhile war strategy. And it will be quite simple for both sides: it is unreasonable to attach escort ships to every cargo packet, so the only way to defend your communications in this case is to send patrols along your threatened transport routes, and to block those ways, that enemy can use to deploy cruisers.
2. Globalization of "thin" assets.
First of all - RP note. We have an ansible in Aurora. Our reports and orders spreads to whole Empire instantly and it is inevitable. So, how we have such things as limitations of fleet or sector command? The only possible answer is in bandwidth of ansible nets. Intrasystem net can keep much more information, than summaries, uploaded in Empire global intersystem net. But it's not an answer for the strategic information level. If our intersystem net can update summaries of whole Empire in 5 seconds, than it is obvious, that it can upload research project information during normal production cycle, if only this cycle is not set to RP-unjustified minimum levels. So:
2.1) There is no need from RP perspective to use colony-attached levels of research project progress. There must be one pool of research data, and local labs can only fill this pool with new data with their different, local-dependent output capacities.
It will decrease micromanagement problem in research branch noticeably.
2.2) This point can reduce also another (and greatly more large-scale) micromanagement problem: transfers in officers pool. Now we need to ignore passage times for officers with new assignments in another locations, because there is no way to pay attention on such enormous pool of smallest shipping tasks. With global passenger net we have this option, it's just a question of time (not very long) to automatically get any number of officers, that has their assignments in any location, that is connected to that global net. And if you want to send smb to frontier or if you afraid of communication threads, then you always have an option to send some important people at the courier or military ship, as it possible for now. The only problem remains with that type of passenger traffic is that our passengers must be already in position when they are in route only. But with our ansible global net we have fair RP reason not to worry about it: officers can execute their duties at their route to local positions, though it will be nice to have a factor "officer at remote" (or even counter of jumps for this net distance), that will reduce his/her bonuses impact. This last option is also usable for those cases, when you just have no desire to send an officer to some locale, and you ready to pay this "remote management" penalties on continuing basis.
3. Smoothing rough edges with game maths.
I'll try to formulate it in such words: micromanagement problem in Aurora have one of it's "centers of mass" in conservative use of utmost oversimplified math. It is obvious artifact of board and early computer games, and it's obsolete with up-to-date processor capacity, graphics and user interface components. There is no need to use linear functions of natural argument, when this function will be calculated by 32- or 64-bit processor - calculation speed will be exactly the same with 32-bit float point number argument, and overall calculation speed will rise negligible with more complex functions.
So. My main point is, that most pure examples of such conservative restrictions can be removed, and these measures will improve situation with micromanagement nightmare significantly.
3.1) Division to missiles and buoys, fighters, FACs, ships and PDCs.
First, we have now 3 unnatural strict and inaccurately named types of vessels: a) fighters, up to 500 tons; b) FACs, up to 1000 tons; and c) ships, more then 1000 tons.
Why this range? Why these names? How to make this all to look naturally in the hands (tentacles, flipper) of another, unhuman race? It is one big entanglement.
Why fighters are fighters? Not all of them are fighters really, good part of them in our campaigns are satellites, boats, shuttles, pinacces, etc. They are fighters in Aurora, because there was similar strict rule of board game, because then we has to calculate maths in that board game. But we need no such rule now.
Why they are named as fighters? Because there was no satellites, boats, shuttles and pinacces in some board game in the past. But now there are satellites, boats, shuttles and pinacces. So, they are small-size crafts - this generalised name is universal enough.
What is practical meaning of this type in Aurora and in RL? Practical meaning is that this type of crafts usually built without slips. Ok, let it be! Have we any need to strict limit of craft, that can be built without slip? No. We can simply bring an impact of size. More size - more penalty for building crafts of this model without slip. There will be some limit, where such manufacturing process will be more expensive, than building in slip. Aurora can display a notice about this extra expense, but if a player wish to build large craft without slip - let it be. Maybe it's some hurry need with it, so let him build!
Absolutely the same with FACs. Why FACs are FACs? Because there was some time, when... you understand. Cards, counters, dices and maybe some monofunctional calculator at the table. There was no another type of crafts in this mass range because there was no possibility to calculate different models or classes with such primitive tools for some old game. But we have another game. Crafts of this mass range in Aurora can be nor fast, nor attack, so they are not FACs at all. I use this range for survey and recon vessels, light dropships, slow and enduring guard corvettes, and small orbital bases, but I have no - no one - class of genuine Fast Attack Craft at all! So what is the general reason to preserve this strict type of vessels?
The only difference is, that light vessels with little crew have no place and simultaneously no severe need in bridge. And in the board game there was no possibility to bring some calc rule, that can reflect this feature satisfactorily. But we have this possibility of calc rule now. Give some bonus for those vessels, that have a bridge - and computer will calculate it without any tension. No need to have a special type or special name for those crafts. That's simply crafts without bridge, and it's all.
The same with maintenance restrictions. There is no need for. Just bring a cost and time penalty for hangar and surface maintenance - the bigger hull, the bigger penalty - and that's all. PDC - it's simply hull without engines and maintenance compartments.
In the same way we can unite all these hulls with missiles and buoys (that are simply unmanned crafts).
The same way with component types.
Why we have separate commercial and military grade engines, that caused tons of question by novices and even old players, and compel us to use two different sets of jump tenders? Because there was some simple linear math rules in old board games. We have, for example, a linear dependence between mass and research cost + crew need of engine - dependence, that makes big engines simply unprofitable without some additional unnatural rule. In RL there is absolutely different dependence: crew numbers of big engines are very small - nor very bigger, that for smallest engines at all, and costs not very big too (there is nonlinear rule). But if we wish to use a forced/compactificated engine, and to have an impact damage redundancy - then crew numbers rise dramatically, even stronger than with linear dependence in some cases. And there is no strict border between commercial and military engines in RL. It's simply a case of reasonable choice of attributes. Add some sizeable cost, crew and rare mineral need for any additional level of each military attribute of engine - and there will be no need in unnatural restrictions, strange types, different algorithms for these types, and, therefore, potential avalanche of questions, exploits and bugs. Players will find optimal types by oneself, and they name these types by oneself in compliance with the usage; no need to prescribe.
There is a simple possibility to unite all three types of propulsion engines: commercial, military and missile engines. All differences between them - are quantitive differences in attributes. There is no need in march maintenance, because this hull is a hull of missile with very short burn life? Well, no march maintenance need - no crew need, and we have unmanned disposable engine (missile, or drone, or disposable dropship - it's a player's choice only). There is some need in inboard maintenance? Well, then we have manned engine with significant burn life. There is no forcing and impact damage redundancy? Well, maybe it's commercial engine, but let our player name it with oneself; yet it will be great, if design window will give some ratings.
The same with weapon types. Why we have so many unnatural conventions with small missiles and missile defences? Because we have the same linear dependence between size and cost. But it's not mandatory! If we will have S-shape or even root dependence (much closer to reality already, than simple linear) - then too small weapons will become too costly for their overall capabilities. It will be no sense in such designs, and, therefore, no need to unnatural restrictions.
We can have no unnecessary types of vessels, no unnatural restrictions, no strange and confusing names, and we will have all functionality, that we have now - and it will reduce micromanagement workload significantly, because there will be lesser need to adjust different components to some strict and unnatural numbers, and will be lesser need to use principally different sets of components for very close models and classes of hulls.
3.2) Cell-based hull and armour model.
It seems to me, that already no need to use these fixed cell sizes, as it was in board game designs. In computer game each hull may have, for instance, 10000 of cells, scaled to summary size of this hull. We can note, that TN armour is a cell armour (because there is quite difficult to calc and display armour penetrating without cell dividing), but those cells can have different sizes from hull to hull. Impact power is a scalar numerical in any case, so there is no need to round it off.
So, there will be lesser designing headache and lesser RP disbelieve with rounded weapon impact powers, rounded missile sizes and so on. Just different numbers and probabilities of cell disruption - which are processor problems (and not significant), not a player or designer headache.