I also found it quite the coincidence that both bug reports were written on the same day.
I was able to track down our issue to Spring Integration. The DefaultSoapHeaderMapper sets the SOAP action on the SOAPMessage (this functionality was added in Spring Integration 2.1). This causes the SOAPMessage to call saveChanges() which sets needsSave to false. After this, the security headers are added. When SOAPMessage.writeTo() is called, it doesn't call saveChanges() again because needsSave is false.
So I think the true culprit is the changes made in Spring Integration. They just excercise an underlying bug in Spring WS.
Incidentally, SOAPMessage.writeTo() sets needsSave to true so if you set on the trace level logging on the WebServiceTemplate, the message transmission will work with the security headers attached.