My apologies for the apparent miscommunication earlier. It is of interest to me that the soft-fork be done which is necessary to put a commitment in the most efficient spot possible, in part because that commitment could be used for other data such as the merged mining auxiliary blocks, which are very sensitive to proof size.
Perhaps we have a different view of how the commitment transaction would be generated. Just as GBT doesn't create the coinbase, it was my expectation that it wouldn't generate the commitment transaction either -- but generation of the commitment would be easy, requiring either the coinbase txid 100 blocks back, or the commitment txid of the prior transaction (note this impacts SPV mining). The truncation shouldn't be an issue because the commitment txn would not be part of the list of transactions selected by GBT, and in any case the truncation would change the witness data which changes the commitment.