The ini format seems like it's designed for text lines containing item=data which end with $crlf, so I'm thinking that most users would not expect $crlf within data to be written to disk.
As /writeini was implemented so long ago, I can't remember the exact reason that $crlf was allowed. It could be that the Windows INI API itself allowed/allows $crlf in parameters, so it was decided that /writeini should match its behaviour. Or it could be that some scripters at the time were using $crlf to write multiple ini entries with one /writeini call.
Looking at the wikipedia page was a little confusing since there doesn't seem to be a unified INI format, so I'm not yet sure which all variants are being supported by hsave/writeini. Based on what I read there, I did find something unexpected related to hashtable or writeini itemnames beginning with semi-colons, as I hadn't realized that INI supported optional comments.
There is no consistency in INI file implementations. mIRC used to use the Windows INI API but there were persistent issues with it so, after years of trying to mitigate all of the issues, and testing the available custom INI libraries at the time (all of which had their own issues and limitations), I was forced to implement my own that worked in a similar way to the Windows API. It was a difficult and time-consuming implementation. You will certainly find quirks and edge cases if you look for them. As far as I am concerned, it works well enough.
Based on what I read there, I did find something unexpected related to hashtable or writeini itemnames beginning with semi-colons, as I hadn't realized that INI supported optional comments.
I have added this to my to-do list and may look into it at some point.
