So, you're suggesting that we specify the amount of industrial output to be allocated to each project as a ratio or proportion among the active projects, rather than as a percentage of total industrial output. Mathematically speaking, "find the sum total number of 'tokens', normalize that as 100% of the industrial output, and calculate that as percentage utilization (the existing system)"
As for queuing, if I understand you correctly, a scenario might work like this:
Active projects (in expected order of completion; tokens): A(2),B(2),C(1) at {40%,40%,20%}
Queued projects (in priority order; tokens acquired/required): D(0/3),E(0/2)
Project A completes, freeing up two tokens, given to D, but not enough to start D, so:
Active projects: B(2),C(1) at {66%,33%}
Queued projects: D(2/3),E(0/2)
Project B completes, freeing up two tokens, D has enough tokens to start, but not E so:
Active projects: C(1),D(3) at {25%,75%}
Queued projects: E(1/2)
Project C completes, E can start:
Active projects: D(3),E(2) at {60%,40%}
Queued projects: none
Based on the use case you described, you want to be able to inject tokens into the system to force a queued project to start alongside existing ones, eg. from the example above:
Active projects. A(2),B(2),C(1)
Queued projects: X(5/5),D(0/3),E(0/2)
Here, adding project X to the front of the queue, and giving it sufficient tokens effectively results in:
Active projects: A(2),B(2),C(1),X(5) at {20%,20%,10%,50%}
Queued projects: D(0/3),E(0/2)
By extension, you could inject tokens at any point in the queue:
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(5/5),E(0/2)
When projects A & B complete:
Active projects: C(1),D(3),X(5)
Queued projects: E(1/2)
You don't have to inject the full number of tokens needed, either:
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(4/5),E(0/2)
Conversely, if a project completes and there are no other projects in the queue to accept the freed up tokens, then those tokens would simply "fall out of circulation" and disappear.
I see a number of potential issues with such an arrangement:
1. Possible to queue a project that will never acquire enough tokens to start
2. Non-constant (potentially highly variable) production rates over the course of a project
3. The assumption that you always want 100% of possible industrial output
An example of (1) would be if we change my above original example such that project D queues up at 0/6 tokens -- it will never start since it can acquire at most 5 tokens from A,B,C -- and project E is also stuck as it is forced to wait behind D. The simplest, obvious solution here is to prohibit queuing a project that requires more tokens than currently circulating in the system. (Other, fancier scheduling algorithms, eg. allowing E to leapfrog over D, would only get unnecessarily complicated and would still have to contend with potential starvation problems. )
(2) is evident from the example above; the percentage of total industrial capacity used by each project can fluctuate quite wildly. Compared to such behavior, the existing system (setting percetage utilization) has the key advantage that the production rate of each project is constant (assuming no changes in the colony's industrial capacity). This also means that estimated completion dates for projects are reliable, which makes it simple to plan ahead, coordinate between different production projects, or even synchronize industry with other parts of the economy, eg. :
a) You can easily and reliably ensure that you've assigned sufficient production capacity to a project must be completed by a certain date -- eg. your shipyard needs to expand and/or retool in order to start building a new class design, and you want to use this time while waiting for the shipyard to ready up to pre-build some ship components -- those components must be finished on time so that they are available for use by the shipyard at the start of ship construction.
b) You can adjust the production rate according to the raw material availability -- eg. say you want to build 10 fighter factories; however, your colony has no standing stockpile of vendarite, and you aren't shipping/shooting it in from elsewhere, just a stable production of 90 vendarite per year from local mining -- then it is pointless to assign the project any more than 120 production (the mines won't be able to keep up).
Matching industrial production rate to raw material availability is also a reason why you'd might want to run at less than full capacity, which brings us to (3). I'm not sure it is safe to assume that you'd always want to normalize the token-based industrial output allocation over a total of 100% of production capacity. A setting could be added so that you could specify for the tokens to be normalized over less than 100%, but that seems a bit kludgy and doesn't really do much to help the issue of inconstant production rates (at least, not without user intervention each time a project starts/finishes). Another possibility is to allow scheduling "idle" projects that occupy a certain number of tokens and "complete" after a fixed period of time or upon "consuming" a certain amount of "build cost" (albeit consuming/producing nothing) -- but this would probably be rather unintuitive and hard to use considering that you'd basically find yourself fiddling with the "idle" project in order to try to (indirectly) regulate the production rates of other projects.
The existing percentage based allocation empowers the player with a lot of freedom and control to make fine adjustments (down to 4 decimal places of a percentage point!) to suit a wide variety of situational gameplay needs, and is capable of supporting different playstyles and arbitrary roleplay rules. I can understand the use case you cited, but I'm concerned that the proposed token-based method would instead reduce the amount of choice and control that players have -- it's significantly less powerful; I'm not convinced the benefits are worth the trade off.
Since you cited "don't have to reduce allocation to something else first", it suggests that your goal may be convenience, or you wish to "preserve the relative allocation across existing concurrently running projects". Have you considered pushing 100% of existing projects back down into the queue? This preserves their relative allocations, and if you set your ship components to build sequentially, all at 100%, then the pre-existing projects will all pop back out of the queue upon completion of the ship components, and resume where they left off. Basically, "drop everything you're doing, build these as a priority; once these are done, resume what you were doing before. " Numerically, this is generally similar to building the ship components alongside with the "whole basket" of pre-existing projects, since in any case you'd have to divert an amount of production capacity equivalent to the build cost of the ship component project(s) away from the basket of pre-existing projects. The difference is that by running both types alongside one another, some pre-existing projects might actually complete before the ship components are done. On the other hand, pumping out the ship components first means that they are available sooner (advantageous in a way, given that components must be available in stockpile at the start of shipbuilding to be used. )