In particular a descriptor can’t and shouldn’t commit to the amount that is sent to it, because the receiver doesn’t have control over that.
(sorry on reflection this 1st paragraph is me mostly repeating your point …)
That’s true but are you not here just pointing to a limitation of using CTV in any case? If your spending of a utxo is constrained in this way, you have to provide an amount which also has a constraint (obviously usually it’s the other way round - you first decide an amount, and then construct a ctv hash). It’s true that CTV supports multi-input so it’s certainly not as simple as “your utxo must have exactly x satoshis + fees for an output of value x”, but it’s also true that the BIP somewhat strongly discourages more than one input, anyway.
I guess it’s like, if we tend to think of descriptors as “a thing that describes an unboundedly large pot you can put stuff into”, then that doesn’t work here, these are not that. They are customized pots of fixed size created dynamically when you’ve already decided what you want to put in them.
(I guess technically these limitations are not only on size, but e.g. timelocking, since you have to commit to nLockTime in advance, also).
If I were trying to be constructive (but in a state of relative ignorance about descriptors), I’d say, the descriptor could have the preimage of the CTV hash all serialized. I’m not sure why that wouldn’t be the correct thing to do, albeit it might not be a “normal” descriptor.