The important point is that I am choosing the amount to be transferred, I am not relying on the merchant for that.
Where I think it gets beyond semantics is when you think of the IT implications. The data that passes along the communication chain from retailer* to acquirer to switch to issuer is extremely sensitive and so has to be secured. This has spawned industry standards such as PCI-DSS, which impose huge costs on all parties in the system and represents a very attractive target for bad guys, creating an escalating arms race.
A true "push" approach would not entail the passing of this sensitive data through this back channel from retailer (or acquirer, if you prefer) to issuer... it would rely on the customer initiating a payment *to* the merchant themselves... the attack surface is a lot smaller. Now, I'm not saying this is perfect.... the question of how the merchant communicates their request to the customer is a difficult one. The Bitcoin payment protocol work, which currently relies on X.509 certificates, etc., shows how hard this is to do on the internet. For face-to-face transactions, you have to find a way for the merchant to share their "receipt address" to the customer in a way that can't be spoofed, etc. The "bitcoin pub" in London does this by displaying a QR code on their POS device, that the customer can scan - but it's not particularly elegant.
(* in many cases, the retailer really does have sight of the card details... the card readers are integrated into POS systems and transactions are routed through branch systems... it's not the case that all retailers never see the card details).