This is not a criticism of those who report bugs, but I just want to give a show of support and a thank you to @Khaled for what he has achieved with mSL. It may have its quirks and bugs, but you can achieve miracles with it. Whilst I think we all whinge at times about the constraints of backwards compatibility that gives preference to decades old, unsupported scripts, I think that we would all moan much, much more if Khaled did a complete redesign and suddenly broke a lot of old, unsupported and unreadable scripts that somehow have become essential.
My wife and I have both used mIRC for literally decades for a very modest one off license fee each and Khaled's support over these decades has been consistently fantastic. I may not have liked some of his decisions about bugs, and I may have a different view on backwards compatibility to him, but it is his software and I absolutely respect his consistent policy and decisions in support of this.
That said, here are a few thoughts on how this might be addressed...
Firstly here are two open-source counter examples to Khaled's backwards-compatibility-first policy.
1. The CMS Joomla has a history of multiple internal re-architectures requiring repeated rewrites of extensions/plugins - and it certainly gets the community riled, and quite a lot of people quit Joomla for Wordpress as a consequence. The Windows IRC app "market" is not dissimilar, and Khaled's approach is definitely better than Joomla's IMO.
2. In order to switch PHP from similarly organic origins to being a more rounded-out object-oriented language, the PHP scripting language has similarly deprecated a lot old syntax over the years, making people update their scripts - and as a webmaster it has been a right pain (which is still ongoing, but deprecations are definitely reducing as this goal is almost realised). But, A) they have always given a lot of advance notice of deprecations, and B) PHP has such a dominant position that IMO they can get away with more. However, the community has weathered the pain this has been accepted because of the overall benefits and the PHP 8.1 language is a pretty fully featured OOL as a consequence.
So how are these relevant to mSL?
A decade or so ago, I did a major remediation of a substantial but ancient & unreadable mSL script into something more maintainable, so I know just how difficult working with such historical scripts can be. The mediation was successful, and I would like to think that my code is much more readable and maintainable as a consequence. And I think that this has given me a good insight into two areas where improvement might be possible.
A. mIRC could (under the covers) have two script engines - the existing "legacy" engine and a new "clean" engine.
B. The "legacy" engine could have deprecation functionality added to help people to identify where scripts would break if they switched to the "clean" engine. This might be i.e. a "deprecation" switch in preferences, which when turned on would create a custom window (or a log file or both) that collected details of where scripts executing scripts had syntax that would break under the "clean" engine. (I am not sure whether this would analyse code at load time or at runtime, but either way it would be a help to switch).
C. Part of the problem with code unreadability and opaqueness is the need to write code using (relatively) low level mSL primitives rather than use advanced pre-written functionality provided by "libraries" or "frameworks" or "packages". dotNET, Python, Java, PHP etc. all have libraries/packages which deliver standardised advanced functionality that build upon the basic language primitives. These help greatly in avoiding developers from reinventing the wheel, and because they (generally) have sensible names they encourage writing more readable code, and because they have many users, they tend (on average) to be better supported. These languages also have a package infrastructure i.e. a repository for libraries/packages and a package manager (e.g. for PHP Packagist/Composer, for Python Pypi/Pip etc.) that help with distributing code to users and help them to update their code, and they also have some coding standards (PEPs for Python, PSRs for PHP) to help developers write readable code which will have longevity, and linters to help identify coding issues. They also have unit testing packages to help with regression testing.
A decade ago I did some thinking around coding standards, packages, package manager, unit testing etc. and even started developing some prototype code. Unfortunately real-life priorities overtook this and I stopped work on these. I still don't have the time to do work on these, but if there is interest from the community I would be happy to be involved in such a team effort.
