You seem to be missing the point that this is a sharp pain point for developers and businesses.  And just plain bizarre that one can't know a fee until after the fact.   too bad if the fee turns out to be 20%, 50%, 100% or even more of your send amount!

Also, if you look at my original proposal in this thread, you will see I am well aware that the fee could change between API calls.  That's why I proposed an alternative with a fee_limit param for sendtoaddress.  That would work fine with the existing pseudo-random sendtoaddress implementation.

Even still, I can wish for something better.  As I said, "perfection to me would be...".

Bitcoin-qt allows the user to view the fee and either send or not.  So what technical reason prevents that capability from being exposed at the RPC API level?   Do we need to add some locking/state around calcsendfee/sendtoaddress?  fine, let's do that.

Or there could be a deterministic alternative to sendtoaddress that RPC users could use when they want a fee calculated.

I believe this is not a technical problem so much as a "la la la" we don't want to fix it cultural problem.

My concern is that if I (or anyone) go to the work to fix it and submit a patch, it won't get accepted, due to core team resistance.

Am I wrong?

My hope with this thread is that we can get some amount of concensus on an approach, so that when it gets implemented, it will be likely to be accepted.