In lieu of responding directly, I'll give my typical meta-response, in which I see this problem-instance as one exemplar within a (much) larger space of game ideas. 4X is (surprise!) not the only genre that exhibits this symptom. Hence, my arch-solution to the problem category will also somewhat transcend a 4X's scope.
- Star bases require more micro management ...
- [Constructor spam] is time consuming, and tedious, and really not all that fun...
- on the really big maps, this can cause each turn to take 3-4 minutes, and all but about 45 seconds of that time is building starbases.
3-4 minutes 
You do not fully grasp how much micro sucks, young grasshopper. By turn 60, I'm already up to 10-20 minutes per turn (because I micro everything optimally), so I never even get to the point where I need to worry about quad-ctors. Still, I fully agree that repetitive micro is less fun than playing those other games. Or lifting weights. Or grading homeworks for pay.
First, I'll pop up one tier and broaden my magpie-eye's view to encompass many game genres. I've been a dev, I'm a C++ guru (hint: read Alexandrescu), and I daydream of being a designer, so I often ponder at this exalted level. (Many of these ideas recur from my previous posts, but I'll add some new content, honest.)
A. Simple UI Idioms, and the Click-Only UI
Many genres start out with beautifully simple ideas. They provide the player with simple controls, which are primitive, atomic, and low-level: basically, you click once (or a few times) to trigger the special action. Then they cast these primitives aloft willy-nilly, and allow the full power of conscious human cleverness to maximize output, efficacy, or whatever. Some exemplars:
- collectible card game (CCG), whether physical or digital. A card has tap state: it is either untapped, or tapped. UI primitve: You tap your card to trigger an action.
- board game (Third Reich). Armor's mobility is modeled via the breakthrough attack mechanism. Combat has two phases. In phase 1, you may declare an attack of 1+ armor units, and declare a mobile stack of nearby armor that does not participate, but only waits. If you win and advance, your mobile stack gets breakthrough movement to pour through the gap (but usually you can only walk 1 hex into enemy armor's interlocking zone-of-control). In phase 2, your breakthrough armor units may attack again, and you may drop your (singleton and very precious) paratroop unit onto the enemy 2nd line and gamble on a 1-1 exchange, which punches a 2nd hole. Any breakthrough armor that didn't attack can now burrow through both holes and fan out behind enemy lines. (Nobody ever has enough units to make three full lines of defense.)
- RPG (paper or digital). Rounds, and actions per round.
- sports, e.g. gridiron football. You may lateral the ball. A lateral or backward pass is a lateral. Primitive action: You throw the ball once.
- 4X (GC3/FE). Starbases/outposts are created/upgraded by constructor modules/pioneers. UI primitives: You build 1 ship, send it, and consume it to upgrade.
Primitive actions can be combined and composed into sequences. This is way deeper than games; it pervades much of human endeavor, including programming languages, engineering, and even business ventures for manufacturing of goods. Also, human players are very clever! Hence, some clever people will deep-think through the entire set of all special abilities within one game, and devise complex in-game engines that combine many individual primitives synergistically, resulting in exponential or outrageous net effect.
- CCG: Any 1-turn kill combo. These typically invest an intricate combination to force open one attack channel, render yourself unblockable (or similar) along it, and preemptively neutralize all possible counters. Other clockwork combo-categories exist:
- Simple chaining. e.g. two cards both have the ability "tap and target friendly X to give him +Y". So every single turn, you tap them both. Essentially, those three cards become one indivisible chunk (like an object in C++), and you want to call its operator()(), without repeating 3 mouse clicks or 3 lines of code every single time. Gosh, it'd be nice if ...
- Positive feedback engine. Most CCGs equate a card draw with a resource cost: some cards let you buy more card draws by paying. Some others have goofball abilities that pay you back when $X occurs. Combine those in wacky ways, and you can net a profit. This can be about an 8-card subset that you squeeze into a 40-card competition deck, which when fully deployed and running becomes very much like a subroutine at the start of every k turns: tap this, tap that, do this, feed this to that, and you net +m resources and side benefits i and j. The complexity is its own deterrent, and generally all combos (in every CCG!) lose to Cheese Speed or Cheese Beatdown. But if you ever think one up and get it going ... it can be the most cackling, knee-slapping, seat-bouncing fun you'll have in two weeks of cutthroat play.
- Turn-1 kill deck. Combines both of the above. Also useful as a theoretical exercise in CCG deck construction. At least 2 exist in M:tG (the Stroke deck and 1 other). At least 1 exists in Chron X (Codeslinger + Lancer Rifle). None exist in Sanctum, because it's half-eCCG, half-board game, and you can't physically achieve the board game win condition on turn 1.
- The M:tG Stroke turn-1 kill deck uses some of the Power 9 (Lotus, moxen) for instant mana, something to make card draws pay you mana(?), deck recursion to ensure that you see everything twice (so that deck sequence for the 1st time through your deck is irrelevant), and mana batteries as a 7-bit register to count up to (i.e. store/stockpile) 127 mana. Then it Strokes your opponent's deck for 125 cards in the top of the 1st inning, which usually wins instantly by decking her. It is beautiful when it goes off. Your opponent is entitled to force you to play by the rules and physically tap every single card, exactly in sequence, which can result in several hundred separate hand/card actions over 10-15 minutes. This might be half the fun, because the entire store and five bystanders on the sidewalk will crowd around your table just to watch it, like Golden State's bench when Klay Thompson kept hitting all those 3s. (Seriously, tho ... build yourself a Lego Mindstorm 8-bit binary register, and watch it count from 0000 0000 to 0111 1111, and probably you'll be bored before it's done.) Maybe after twenty such wins (or two) ... the novelty/excitement wears off, and it just becomes tedium.
- board game (Third Reich): The oddball/weird mechanism of breakthrough attacks instantly emerges as the uber-arch-tactic in the game. Tactical skill in the game consists largely of how well you can set up and conduct breakthroughs 3 turns out of every 4. Conversely, defensive skill, and 95%+ of defensive positioning, consists of preventing breakthroughs (or knowing when to sacrifice half you nation's land space and retreat to avoid an even worse encirclement -- which is actually historically accurate). Ergo, most of the game consists of both sides hypothetically-doodling all possible breakthrough-gatherings of local forces. So it should be the UI primitive, and not rely on the (mind-numbingly laborious) manual repetition of click-only primitives.
- RPG: I suppose teamwork amongst a party can be an emergent, scriptable effect. Hilarious: it's very similar to a good gridiron football team: your O-line (fighters, paladins, maybe a cleric) stops the big baddies' dumb rush, your QBs (mages, maybe archers) bomb/snipe from safety, your trainers (clerics) heal whomever needs it.
- Battle preamble. In some digital RPGs, and maybe Runequest, there are no Fireball-class spells of mass destruction. Instead, you have little pump-up spells. So before, or at the start of, every battle, you run through a canned script of these pump-ups, where your backline spellcasters' first 1-3 rounds of actions are all scripted by rote. In classless RPGs (cf. Jeff Vogel's Exile/Avernum), I happily exploit this by having my dumb jocks take level 1 in mage and cleric spells, just so they can cast a few weenie pump-ups and heals. It's by far the best use of those skill points. In Runequest, we joke that this is your hallway habit, as every adventuring group pauses outside every closed door and casts 1-2 rounds of battle magic on themselves before they open it.
- Sports: You can script a trick-play punt return, e.g. a lateral (or fake lateral). You can't quite script The Play (seven laterals for a game-winning TD), but it's happened so often that it's become a meme. (In rugby, you do script and practice it, since the rules of the game reward higher risk.)
- 4X (SE5). Tactical combat gets to be not-fun when you realize you've played the same combat out a hundred times (and each one is wasting 2-5 minutes wall clock time). Many of my tactical combats follow the same high-level program: { fly away until point defense kills all fighters; fly circles until antiprotons outrange all ships' cannons; weave sine curve around planet's missile range until bombardment kills all platforms; bring transport and drop troops; speed up to 8x and wait out tactical clock }. The details change, but the program is always the same. Monotony is a special kind of gamer hell.
B. Composition of Primitives
In many game genres, the set of primitive elements in the game space hits some critical threshold that allows fantastic, eye-popping engines (Rube Goldberg machines, clockwork devices) to be embedded. These are often emergent constructs that nobody could anticipate, because they rely on intricate combinations of primitives that were not fully comprehended by any of the primitives' designers. Human ingenuity will find them! (and then open competition will kill them off, but that's a different problem)
But having found them ... you're still mostly forced to use the same click-only UI to manually walk through your intricate clockwork program, one step at a time. Very few game genres explicitly acknowledge the existence of composition of primitives as a 1st-class element, and provide higher-level UI or organizational support for them. (In the real world, we do exactly this, hence we have assembly lines, server farms, functions in all programming and script languages, and classes in Java/C#/C++.) I loosely conjecture that this lack of support arises from -- a collective smallness of vision?
From a CS standpoint, composition of primitives can give you function call, which is "halfway" 
to being Turing-complete. (Specifically, conditional and iteration suffices to be Turing-complete(!). Function call allows recursion, which subsumes iteration -- ergo, Lisp. So composition + conditional suffices. Hence, composition alone is already very powerful -- and in every endeavor except gaming, we've acknowledged this by making composition be a primitive language construct, and building wonders on top of it.)
C. Lifting the Level: Composition through ... Automation?
Hence, I see this not as simply an issue of GC3 constructor spam for starbase upgrades, but (much) more broadly: as the gap between primitives and composition. Beyond the click-only UI, what can we add? The obvious lesson from programming et al. is: just bite the bullet and go to a full script language, with a complete game engine API under it. Make it Turing-complete, because it'll end up there anyways. I will, of course, always lean in this direction, because I think it is the arch-solution to this problem-category, across all genres.
- 4X (GC3): Starbase constructor spam is similar to the M:tG Stroke deck's inherent tedium. There's a simple goal at the top (upgrade this starbase along path I-J-K-L-M), with a complex clockwork underneath it (planets build ships, ships fly to starbase, starbase alerts you). With a click-only UI, we must manually click every decision in that clockwork by ourselves, with our mouse and the wall clock. (I would do this regardless, because I micro everything ... but even I don't enjoy it.) Some candidate solution-branches:
- Replace constructors with something else. (cf. the OP's post) The intent is good, but ... realistically, your vision is probably not going to trump the designer's vision at this late stage. From GC2 until now, the constructor-to-starbase mechanism has been deeply etched into the design for many, many years. Nobody is going to just throw all of that away in the last ~3 months before release.
- Automate the constructors. (numerous) Many posters have suggested a project-like link from 1 planet to 1 starbase, which would compose the primitives of UPSTAB { build constructor; constructor goto starbase; starbase upgrade path }. Maybe then as long as this UPSTAB project runs on that planet, it will quietly do that until the starbase reports that it's done.
- Lisp(-ish) script. (me) Then you could script the simple UPSTAB program yourself, or modify/customize it however you see fit.
- CCG: I have pondered a novel new dimension in eCCGs, which embraces exactly this idea (in all its sprawling splendor). First, I'll draw a contrast:
- Most (e)CCGs that provide tap-state implicitly assume (by forcing a click-only UI upon you) that most decks, most of the time, don't tap. That is, most cards (in successful open competition decks) don't tap, or tap only to pump themselves up (i.e. zero interdependence on any combo), or tap in very simple combos: pairs, or maybe trios. Tapping is presumed to be an abnormal action. Ergo, you are subtly discouraged from building intricate, tap-heavy, combo-dependent and sequence-critical decks, which is tantamount to encouraging players to build only the simplistic decks (like Cheese Speed or Big Stupid Mil).
- Many CCGs also tolerate the existence of these clockwork combos. By hook or by crook, they did end up in the union of all card sets. No designer ever sat down and explicitly decided I shall put this card into the game so that it enables that huge combo. Instead, they emerged through competition and human cleverness. You can build such decks if you want to, and you'll win a few games that you shouldn't have. Generally, they are their own punishment. They're hard to get running, they don't win enough to be dominant, and they're inconvenient to micromanage. Nothing in the game's UI or rules helps you to manage the complexity; you just click with the mouse.
- Hence, I postulate a new (tier of) eCCG: the Rube Goldberg mousetrap CCG. I explicitly lift clockwork combos to 1st-class by establishing that the premise of the game is that you shall construct clockworks, and that your clockwork will fight my clockwork. For example, you may need to build 3 separate pyramids of card-groups, respectively a Battle Group, a Lookup Table, and a Mana Market (haha!), which interact in wacky ways. Tapping evolves from being an abnormal action, subtly discouraged, to being a nigh-mandatory action, and even then not enough. The whole point is to out-do the other guy's mousetrap by constructing a better mousetrap.
- The UI explicitly helps you do this by defining higher-level UI idioms (obviously borrowing from 40 years of programming languages). Just for example:
- Tap-chains: a chain of cards, like dominoes (or groups in PowerPoint). Tap the chain and they all tap in sequence.
- Tap-trees: a chain with branching factor 2+
- Target-graphs: drag-and-drop composable as explicit arcs that glow and hover over the board. Lets you lock-in a target (so that your tap-tree doesn't bug you every time).
- In/out flows: Some taps produce a new card or thing (e.g. "tap and pay 2 cyber to create Shock Treatment in your hand"). Some taps consume a thing (e.g. "tap and target a card in hand: discard that card to gain $X"). You compose outputs to inputs with drag-and-drop links, as a graph editor. (During play, they're animated with little icons scurrying down the arcs, like a EE circuit emulator.)
- Target currying: A tap-tree may consist of 5 dudes who all target $Q to ding $Q. Click "curry target" to create a new target-box, drag-and-drop from all 5 dudes' I-need-a-target box to the new target box, and your tap-tree now all targets $Q, where $Q is a variable. Your tap-tree could chain together N-1 mandatory inputs per card, so that all cards are happy except they all need a $Q, which is not yet specified. On each turn, you tap your tree and the UI engine asks you, Who is $Q for this salvo? Ergo, a fire team pattern (which is historically accurate in squad-level tactical combat). More generally, currying allows you to partially-satisfy (freeze, bind, lock in) some arguments of an n-ary function, which reduces the remnant to a k-ary function, for k < n.
- Hence, halfway through a game in progress, your game board will look like a freeway overpass or CPU circuit, with cards organized into trees, graph links arching over groups of card-trees, target links from your card-trees to her hapless target-cards, ..., and maybe glider-proteins spawning off your opponent's own engine that you just took over, encoded on your injected card-engine's introns. That's a lifting-of-level. It's the 3rd dimension of complexity floating above and over every 2D CCG on a flat tabletop (and, by extension, over every board game, RPG castle grid, and 2D 4X). The set of your individual cards in play would be a tiny, tiny fraction of the real complexity. And you're dueling the other clockwork at the level of high-level patterns you freely devise, way above the details of one card.
- Ergo, I think this can only be an eCCG. You can't do this with paper cards on a tabletop, because the premise is that we explicitly add the layers above both of those.
- The card set itself also explicitly supports such clockworks by simply ... embracing the complexity. Have cards that do input/output, some that do conditionals, some that chain linearly (or chain-react), some that target friendly units, some that target enemy things. Very soon (I think), the union of card capabilities will cross the threshold and enable clockworks to be composed.
- Finally, the game shall come with a few stock AIs ... and each one is simply a mediocre mousetrap, which utterly crushes your card-at-a-time sheep or newbie deck, until you learn to build a more powerful mousetrap. For example, maybe your best stud asset is a 4, but my weenies all benefit from my Artillery tap-tree, so they'll eventually be 2+9s, for cheaper, and I have more of them. You better build up your own tap-tree that pumps your guys by +8 ... or does other things that negate my tap-trees. Briefly, if your side of the board is less cluttered with your own 3D floating arcs, links, chains, groups, and other active links -- then you're doing it wrong, and you're probably losing. The lesson is also the incentive.
Getting back to GC3 constructor spam: I am ultimately agnostic about this issue.
- Yes, it's micro-intensive. But I'm already in micro-hell, so I don't see that as any more of a problem than the rest of GC3's UI already is
- I trust Stardock to have some anti-spam tricks up their sleeves. I'm willing to wait for Beta 5 (and Beta 6
if there is such a thing)
- Even if there is no magic solution in GC3 Release, that's not much of a show-stopper for me. It means my market niche is still fallow, and maybe I can still get there first
GalCiv3 Forums
You do not fully grasp how much micro sucks, young grasshopper. By turn 60, I'm already up to 10-20 minutes per turn (because I micro everything optimally), so I never even get to the point where I need to worry about quad-ctors. Still, I fully agree that repetitive micro is less fun than playing those other games. Or lifting weights. Or grading homeworks for pay.
to being Turing-complete. (Specifically, conditional and iteration suffices to be Turing-complete(!). Function call allows recursion, which subsumes iteration -- ergo, Lisp. So composition + conditional suffices. Hence, composition alone is already very powerful -- and in every endeavor except gaming, we've acknowledged this by making composition be a primitive language construct, and building wonders on top of it.)
if there is such a thing)