I've gone back to trying to make carriers work, and run into some technical issues.
1) It is possible to sling fighters by engaging the jump before the carrier finished charging its FTL. The fighters wind up in the next system while the carrier remains behind. This would allow a single pad carrier to project any number of fighters without having to make multiple ferrying trips.
Suggested solution: If fighters can inherit the charging status of the ship mounting the pad transporting them they wouldn't be able to jump before the carrier.
2) Fighers on the pad (test) cannot be selected without selecting the carrier, nor can components be selected without selecting the pad. Movement orders to the pad also get interpreted as follow orders. All of these appear to be consequences of the pad (test) mask encompassing the entire pad.
Speculative solution: I don't know if it's possible, but if the mask was hollow with only a half or quarter tile's width around the edges needed only for connections the pad would interfere far less.
3) The pad (test) cannot be overlapped with engine exclusion zones. This is unavoidable given its purpose, but makes putting engines on impure carriers more difficult. The easiest place to put landing pads on mixed use ships is at the back in the exclusion zones for the engines. The parts having the same name implies that if the test version works out the old version will be discontinued. I would urge you to not do that.
From a not-so technical standpoint, the cheapest pregen carrier is too expensive to have both it and a useful fighter the first time you have to make a jump. A more minimalist carrier with a fighter scale cockpit, reactor, and jump drive and no factories would be more useful.
