Hi Billy,
Restricting the number of inputs is necessary to preclude TXID malleability. Committing to all of the information required necessitates that the number of inputs be committed.
This allows us to build non-interactive layer 2 protocols which depend on TXID non-malleability (most of them at writing).
You raise a good point that allowing *any number* of inputs is an interesting case, which I had discussed offline with a few different people. I think the conclusion was that that flexibility is better left outside of the OP directly.
If you want an any number of inputs template, and we enable something like OP_CAT (e.g., OP_CAT, OP_SHA256STREAM) then you can spend to something like:
<hash data before # inputs> OP_SWAP OP_CAT OP_SWAP OP_CAT <data post # inputs> OP_CAT OP_SHA256 OP_CTV
And then pass in the # of inputs and sequences hash as arguments to the function.
I can respond separately to your bitcointalk post as you ask a different set of questions there.
Best,
Jeremy