It is indeed possible to subscribe and send messages using temporary queues, however this is only possible if the same connection that SUBscribed to the temporary queue (e.g. /temp-queue/tom) is also the one to send a message to it.
The reason for this is because the hashmap of temporary destinations is stored on the StompSession level so a second session does not locate the user defined name "tom" and therefore sends it to a brand new destination.
I have worked around this by changing StompSession convertDestination(String) so that when the StompSession receives a JMSReplyTo to a temporary destination it will store it in its temporaryDestination cache thereby ensuring that if the receiver then responds to the message, it can relocate the correct temporary destination.
Perhaps this (or similar fix) could be applied to stompconnect 1.0.1?