Support/investigation activity may require necessity to replay logged/sniffed FIX messages that are transferred on wire as mere strings. An option to build a FIXMessage from such a string may not be good enough because FIXMessage constructor may rearrange the fields that ruins the idea of replaying especially for specific FIX dialects. Applying a custom fields ordering is not good enough either because it requires efforts to prepare such a custom order definition and yet it is not easy to control whether the applied order corresponds the original message order.
The best option to ease the replaying could be an ability to send a raw, completely unprocessed string as a message. One sending such a string could update some specific message fields on the string level upon necessity. The proposed change offers an ability to send a bare unattended string.
Personally, I use such functionality from Python API replaying real logged FIX messages against tested clients. Some fields like target or sending time are updated on the Python level along with recalculating of body length and checksum. This can be done easy on the string level and the rest parts of the message can be replayed "as is".