There is a payments reason this is hard that has not come up, and it explains why every app you have found does the split after capture rather than before.
One checkout produces one authorisation. Not two, and not one that can later be divided. So splitting into two orders before payment means two authorisations, which in practice means the customer goes through checkout twice. Everything else is a shipping split, which is what Shopify’s Split Shipping actually does: it groups items and charges shipping accordingly, and it still captures a single payment against a single order.
The obvious workaround is to capture partially, take the in-stock portion now and the pre-order portion when it arrives. That does not work, for two separate reasons and either one is fatal.
Capturing less than the authorised amount releases the rest. You do not get to come back for the remainder later, because on most gateways an authorisation supports one capture and the uncaptured balance is returned to the cardholder’s available credit at that moment.
And even if it did support a second capture, the authorisation expires. Seven days on most cards. Pre-orders are by definition longer than that, so the hold you would be capturing against is gone before the stock arrives.
Put together, that is why the app ecosystem splits after payment. It is not that nobody has built it. It is that pre-capture splitting requires either two checkouts or a stored card charged again later, and the second one is a different product with its own failure modes, because a later charge is a fresh authorisation the issuer scores on the day rather than a capture against something already approved.
Which brings me to the thing worth checking, and I mean it as a question rather than a correction.
Your stated reason for wanting the split was to help your team tell in-stock and pre-order items apart for order management. That is an operations visibility problem, and this whole thread has been answering it with payments architecture. If the money can stay as one order and one capture, tags, line item properties and a saved admin view get you the same operational separation with none of the above, and Sandy’s option (b), holding the whole order until the pre-order item lands, keeps the payments side to a single simple transaction.
The payments split is only worth its cost if you genuinely need the money in two parts, on two dates. If you do, that is the deposit-and-balance shape, and it is worth designing deliberately: take the in-stock amount as a real payment now, store the payment method, and charge the pre-order portion as a separate transaction when the stock arrives. Expect a percentage of those later charges to fail, tell the customer the date in advance, and decide beforehand what happens to the reserved stock when one does.
If the money can stay in one piece, keep it in one piece, and solve the visibility problem where it actually lives.
We run an Aussie-founded pre-order app 
)
I see you’re already in conversation with one of our friends from the preorder space. Have you considered holding the order until the preorder item is in stock?