mIRC needs a change in the servers list storage and distribution implementation.

mIRC should do the following:

Default servers should be stored in the file: servers_default.ini
User defined servers should be stored in the file: servers.ini

The UI for browsing servers should include a drop-combo: "All Servers / Default Servers / User-defined Servers"

Migrating to this new paradigm, mIRC will come with a new "servers_default.ini" file and mIRC will delete all exact duplicates from "servers.ini" leaving behind only the user-modified servers and the historic-deprecated servers from a bygone era.

Now when mIRC is installed, new servers can always accompany it without destroying the user-defined servers.

Particularities:

The drop-combo selection of "All Servers / Default Servers / User-defined Servers" will specify how mIRC behaves when connecting to and rotating between servers.

* If "All Servers" as last selected, mIRC will prioritize connecting to User-defined servers first, and failing that, will move onto servers in the Default Servers list within the matching group name.
* If "Default Servers" was last selected, then only servers within the Default Servers list will be rotated through when connecting to any groups within this list. (If said group ONLY exists within the User-defined Servers list, then it will still attempt to use one of those servers.)
* If "User-defined Servers" was last selected, then only servers within the User-defined Servers list will be rotated through when connecting to any groups within this list. (If said group ONLY exists within the Default Servers list, then it will still attempt to use one of those servers.)

Servers will be considered as a "Duplicate" and "overridden" if they share the same exact "Server Description" name between both files.

This behavior will enable updates to mIRC to allow new servers to be introduced to and removed from an existing Server Group, with user-expectant behavior and security in mind. User-defined definitions being preserved and prioritized, and, used exclusively so configured.

An augmentation to the drop-combo suggestion above, it could instead use an "[x] Include Default Servers" checkbox instead if you think this would make more sense to users.

Level 2.

mIRC should do away with the .ini format for servers, and switch to an .xml format instead. Still using a single CRLF delimited line for each server entry, each member can be uniquely named with quoted fields that are easily extensible over time. Addition of new fields like "Last-modified" time, "Added-on" time, would become possible without causing a bunch of compatibility problems.

Drop-in compatibility would be as simple as mirc.exe first detecting for .xml files, and failing that, detecting for obsolete .ini files instead.

I think that are many scripts based on servers.ini. Making this, the scripters must change their scripts. Other part of discussion that you said to have 2 files .ini, one as default, another with users preferences.

I don't think that will increase the performance or do something best (excepts when mIRC update the servers.ini), instead, this will make a headache for scripters to modify their scripts. But, the decision goes to Khaled. My opinion is that the user decides to update the servers.ini or not, when the user installs or updates the mIRC and this option is included in the installer.

That one specific endeavor is a huge deal and needs to take center stage high priority. It's not a mere whimsy activity.

How can a user update their servers if they also have 20 custom servers they've since added and edited of their own?
There is no merge or migrate feature, yet, and so it should be done that the two lists be made separate. Just like your spell check dictionary in every platform.

If some nimrod wrote a script that manually parses the default servers.ini file, and can't be bothered to update their script, then they should continue using a singular servers.ini file. The rest of us don't care about that nimrod.

It is normal for scripters to make assumptions about how features work and to create scripts that parse the servers.ini, mirc.ini, and so on. It's not ideal because formats can change but it does seem to be common. That is why backwards compatibility is important.

In this case, there are no plans to change how mIRC uses INI files for the servers list or other features.

That said, I looked into the idea of merging of new and old servers.ini files about twenty years ago, going as far as creating an interface for it. In the end, I decided it was too complicated for regular users, and messy even for techies.