Repeating keys in order to store multiple values is not very elegant, agreed. But maybe you also want to structure your keys, e.g. you want to store the start and end timestamp of two phases A and B. You'd then too have to resort to some naming convention like "A/start", "A/end", "B/start", and "B/end". Maybe you even would then like to filter your messages with a certain timestamp within phase A or phase B. There are lots of things that could be expressed more easily.
If went down that road, maybe we better represented the properties as an xml document. E.g.
This would allow us to have arbitrarily structured properties as well as to validate them against an xml schema. One could think of an XPath mapping to access these parameters with the "old" syntax, so you'd get value-2 with the key "my-property(2)" or the end of phase A with "phase-A/end".
Cool stuff, but I'd personally rather stick to the simple parameters that already exist. I generally find it good enough to put more complex things into the body. The example you describe seem a little bit esoteric in the context we use JMS for. I believe that complex filtering and routing at an ESB level often leads to difficult to maintain system. I prefer a controlling process manager instead. But maybe you can find a real use case that helps to better understand your idea.