It's entirely possible that Magic has broken something and you might have to submit a support ticket to isolate/sort this.
Are you doing something like: HttpCall('POST','http://url.com','message=<message>testing</message>','') ?
Its kind of interesting to see the 3.2e convert into a JSON ish fashion. If my above assumption is correct I would have expected the 3.3g result albeit without the ":" at the end. Can you also try catching it in wireshark?
Obviously you are seeing a different output between the two versions with the same script catching them so thats not in question. Can you download different 3.3x versions and see if it breaks in a specific version? 3.3e release notes mention some stuff in this area.
141969 If 'Accept-Encoding: gzip, deflate' header is present in the URL, some garbage data was displayed in response to HTTPFramework=DotNet/Soap.
151005 The function HTTPCall() was not working with Digest and Basic Authentication when HTTPFramework=DotNet.
3.3d added support for PATCH verb.
So they have certainly been tinkering in this area and its possible they have upset something.
I can't really give personal experience with this anymore as we have since offloaded our HttpCall work to an in house dll due to a need for better TLS support as most of our stuff was https and Magic native TLS support wasnt cutting it.
I don't know if you try doing a http communication inside a .net snippit in xpa if that has full TLS access or not but if its not a concern then you could always try writing a central program with a .net snippet to handle your http calls from.
You could also maybe try the different HTTPFramework types (D is default I think, the other is J) to see if that makes a difference. Also whilst HttpPost is depricated it will still work if thats the verb you are trying to do so it might be worth giving that method a try to see if there is different behaviour.