Getting to Mageia 7 from Mageia 6 was horrid, but now that the deed is done the result is generally pretty nice. I have a few comments.
The biggest positive I see is that there have been a LOT of memory leaks fixed in KDE in M7. That is a huge improvement which should have a major impact on stability for systems that are up for a long time. So far, I won't commit myself on that; mine has been up and down a fair amount as I deal with this issue and that issue, At the present time, it has been up for about 3 1/2 days and I don't see any leakage from the major KDE components (kwin_x11, plasmadesktop). I have seen some leakage in chromium. There may have been some leakage in firefox; not sure. And the fact that I am not sure actually is a substantial improvement. There was also a race condition in the desktop effects when entering expo mode. So far, since the upgrade, that really very annoying problem has not bitten me; maybe it is fixed. I can hope so anyway.
I also had some intermittent issues regarding some of the features of plasma. I won't enumerate them because they seem to be gone now. I have this idea that there was some configuration things in M6 that are changed in M7 and they caused occasional problems until, in the normal course of things, KDE/Plasma rewrote those files, likely during a logout or reboot.
The biggest negative I see are the browsers. Both firefox and chromium are Pissing. Me. Off. Both browsers are incorporating more and more user security, and they are doing it their way. Well, their security changes are colliding with MY security protocols in a big way and, as I study how they are doing it, I want to disable that and continue to do it my way because my way suits my purposes better than their way does. But I can't disable their protocols totally, and I therefore have some non-functioning capability that I have not totally figured out. I am having similar problems on all my virtual machines. Similar, but not identical. Some functions won't work in M7 but will work in OpenSUSE Leap 15.1 or Mint 18. So, for now, when I hit a problem in one environment, I try it in another environment. If it works there, I keep on going. Ugly, but for now workable.
Maybe I will give Opera a try...
Changes in the network-scripts are biting me. VLANs are no longer being handled correctly. A route is being written that effectively disables the vlan. I have a pretty good idea what is going on there but I have not yet decided on the best way to handle it. I am inclined to say that the change in scripting has improperly broken VLANs but it could be that my VLANs on this box are not properly configured and the misconfiguration was tolerated by earlier versions of Mageia but is no longer tolerated. In any event, I restore the vlan by just removing the route.
The documentation on this subject seems to be very distro-dependent and some of it is contradictory. I've been following the Redhat model since that is the ancestor of Mageia, but maybe I need to reconsider that. I have found no documentation at all on this subject for Mageia.
Given that testing this will involve at least several reboots, I have given it a low priority to sort out. When (eventually) I do that, I likely will write some documentation.
On bootup, the boot process hangs for about a minute as the system "waits for hotplugged networks to start". This entire workstation is configured with static networking. I don't use network-manager here, and I have removed all interfaces from ifplugd. The way I use the system, any of that automated networking really gets in the way. So, I would love to kill that hotplugged networking thing, but I have not figured out how. I've rooted around in /lib/systemd but don't have it figured out.
Again, it is a bootup thing so gets a low priority.
Also, on bootup, sddm won't start. I keep getting kicked into some other desktop manager (lxde?). I have to move to a console, log in as root, and start sddm. I used MCC to enable sddm on startup, but it doesn't seem to work. Every time I check on it, sddm has been disabled again. In fact, I can go into the system services section on MCC, check the "on boot" box for sddm, select OK, and leave that section. Go back into it and look, and "on boot" for sddm is unchecked.
I have not yet dug into that. Where does MCC save its config information for system services?
So, that's where I'm at. I expect the reduction in memory leaks will make the system a lot more stable. At least, I hope it will. Other than the browser issues (which are multiple and not fully understood at this time) the other issues are (mostly) minor annoyances.