Well the thing is bitcoin uses heuristics to intelligently select coins to use intentionally to minimize the transaction weight on the network etc.  Masterchest does none of this and just follows the rules whether that results in an optimized transaction or not.  

Like a car from 50 years ago, it still gets from A to B but it could be more efficient.

I think the best way to come at it is to just go straight for proper adaptive transaction crafting and make Masterchest smart enough to handle some context - eg a couple examples from one of my git comments:

Can I craft this transaction in a way that leaves unspent inputs available for further Master Protocol transactions from this address same block?
Can I craft this transaction in a way that minimizes the fees payable by the user?
Can I craft this transaction in a way that consolidates some of the small reference outputs (.00006 etc)?

And so on...  After that we move from MP to Bitcoin considerations:

Can I craft this transaction in a way that minimizes transaction size on the network?

Etc Etc

Appreciate the offer but I think I'll be OK - after looking at this a bit more I actually don't think it's that cumbersome to look at increasing fee after initial transaction creation & signing - even if the fee does need to be increased (and the total input doesn't cover it), that's at worst two extra >dust inputs which would be about ~300 bytes so not enough to trigger another fee increase - that nullifies my concerns that we'd get into a loop adding inputs to cover fees which grows the tx to require more inputs thus more fees, which grows the tx and rinse repeat.  Worst case is we have to go back and change things once and resign, which isn't so bad.

Thanks
Zathras