It's funny that you're blaming the Quicken programmers, when it's BoA that is messing things up by sending to Quicken the pending balance rather than the posted balance. So the Quicken programmers need to construct an elaborate work-around to download the pending transactions and the pending balance, and then back them out of the balance for reconciliation. If BoA simply cancels a pending transaction like a pre-authorization, and doesn't send that cancellation to Quicken, Quicken's background tracking gets fouled up. And because Quicken can have transaction downloads in the cloud and from the desktop, and needs to keep them in sync, it can get very messy. There is an industry specification for electronic transaction communication between a financial institution and third-party software like Quicken, and it's likely the BoA programmers haven't got their t's crossed and I'd dotted.
I'm not saying this isn't a pain in the @$$. Nor that Quicken doesn't have to come up with a way to fix it. I'm just saying that the Quicken programmers certainly understand how pending transactions work, but they aren't the ones who made the mess.
No, BoA made changes, and Quicken has to try to keep up.
I only said Quicken isn't responsible creating for the problem; I didn't say Quicken isn't responsible for trying to figure out how to fix it.
As for pointing this out, there are multiple posts on this forum about this issue (such as this one), with BoA as well as a few other financial institutions which have switched their connectivity protocol.