Sebastian, the problem is that those casinos misunderstand the structure of transactions and believe in "from addresses". No amount of patching will correct the moral failing here, which is that they are doing payment processing without understanding the network or protocol they are using to do it. I have a document which discusses
"from addresses" and surrounding misunderstandings.
To make transactions which require a recipient's signature would require a soft-fork (to introduce the new transaction type), and would add an extra signature verification to the process of validating transactions. Since transaction validation is done by unpaid nodes, you would need a strong usecase (and this is not one, unfortunately) to justify the added load on them, since Bitcoin's centralization depends on these nodes operating freely and diversely.
Edit: Here is a similar idea: suppose that instead of signing every output, you sign only your change output as well as a recipient's key. Then the recipient sees the transaction and chooses her own outputs, which she signs, and the transaction is invalid (i.e. not minable) until she does so. This gets the recipient cooperation that you want, but also allows the recipient to choose her own outputs (for
merge avoidance) and also choose her own fee (because presumably she cares more than the sender that the transaction actually gets confirmed).
This is still a forking change of course, but it gives you some extra usecases so I figured I'd mention it.