I actually had a use case in my case where it was possible, and that was the check I used to get around it, just configured it so that I always generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx. It was either that or making sure I had no unspent outputs. The use case of doing it was laziness in just creating a single key.

On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr <luke@dashjr.org> wrote:

On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> This was one of my concerns when implementing a scheme where you sign a
> refund transaction before the original transaction is broadcast. I
> originally tried to pass a hash and have the server sign it. However, I
> had no way to know that what I was signing wasn't a transaction that was
> spending my coins! So I changed the code to require sending the full
> transaction, not just the hash. The other way to mitigate this is through
> not having any unspent outputs from this key.

Well, there's no use case to sign with an address that has already been sent
coins. The main problem with enforcing this is that you can't exactly stop
someone from sending to an "identity" address.

Luke