It is, seems the 2.4GHz config isn't equal:
.disable-pmkid=no
Why aren't you using CAPsMAN?
It was probably left there from a previous update or configuration import, because I normally reset my devices and configure them in the same way. In any case, I removed the explicitly configured disable-pmkid=no setting so both configurations are now identical in that regard.
Regarding CAPsMAN, I simply prefer to manage each AP and its configuration manually. I only have a few APs, so this approach works well for me and gives me direct control over each device.
My question is Erlinden why are you trying to make is seem as though Using Capsman is normal or preferred!! Not using capsman in many instances is actually a better way to proceed and a much cleaner setup. Furthermore not using capsman doesnt mean many wifi settings are not available.
My response is Mr Maison, well done!!
Thanks for the question @anav ! With CAPsMAN you can prevent these kind of differences. Besides, there is the possibility to set settings per radio. So, in my opinion, preferred.
Like, creating security on one place and referring to it in the config. Same for more advanced settings like steering. I have a development background, so my "wiring" is not the same as yours.
What can't be handled by CAPsMAN?
Hope the change helps solving the problem.
I'm wondering that as well. I have rules to setup each radio by it's MAC, and then use either common or specific config files behind that. And, once provisioned, you can always use the WiFi tab in CapsMan to alter things on the fly, but with all AP's manageable from one place, making comparisons easier.
Capsman is preferred here and has been for a while. It is a consistent interface for 1 or many APs - for consistency, If I were confronted with a new installation, it would be Capsman regardless of the number of AP's
Yeah a bit tongue in cheek here, but after flailing about with early capsman and dealing with so many changing renditions of wifi, and after mastering vlans without capsman, I dont care for it and moved away from MT wifi, and only use tp link smart access points. They just work out of the box and never have the gazillion wifi issues I see CONSTANTLY on these forums. So I guess you are gluttons for punishment 
I do have some older capacs, and only one is left in use but its solid in the basement for our gym use (mostly to use for zwift rides).
As for simplicity, my capac setup was transferable to any other wifi setup in minutes, just have to change the vlan if using different SSIDs, etc...........
Regarding CAPsMAN, I used it in the past, with my RB4011 acting as the main CAPsMAN controller. At that time, my network setup was different. After some updates and changes to the Wi-Fi drivers/packages, I had problems with the configuration and the management of my hAP ac² devices became messy, so I eventually moved back to managing each AP individually.
Today, the RB4011 is mainly responsible for routing and the rest of my network infrastructure. I originally bought the Wi-Fi version because it was my main and only primary Wi-Fi device at the time. As my network expanded, I added dedicated access points.
My current setup consists of three hAP ac² devices and one hAP ax²:
hAP ax² in my office;
hAP ac² in the living room;
hAP ac² in the outdoor/annex area;
hAP ac² on the upper floor.
RB4011 also provides 5 GHz Wi-Fi coverage on the upper floor, other side of the house.
I prefer managing the APs individually because I use location-specific settings. For example, on the hAP ac² in my living room, I reduced the 2.4 GHz transmit power to 11 dBm. Even after changing channels, I noticed interference affecting my soundbar, and reducing the transmit power solved the problem. Since I also have several Sonoff and other IoT devices on 2.4 GHz, I prefer having direct control over each AP.
Since I only have a few APs, manual management is simpler for me and works well with the specific adjustments I need for each location.
Don't you think that, in this case, it wouldn't be any more trouble to set it up in CAPsMAN?
From what I gathered, that incorrect configuration mentioned above came from a beta version of WinBox 4, because it didn't appear as selected when looking at it in WinBox!
and each hap ac/ax essentially has the exact same configuration, the only thing that changes, as you noted, are some idiosyncracies for individual settings, and of course which vlans go to each device (for the appropriate WLAN/SSID). Easy peasy lemon squeezy!
Example using CAPsMAN
For instance, I ran into an issue where the interface wasn't properly linked; in my case, on the hAP ax, wifi1 is 5.8 GHz and wifi2 is 2.4 GHz, whereas on the hAP ac it's the other way around—doesn't that cause problems? I was thinking of having the hAP ax manage the network, but could I do it with the 4011 instead, considering it uses Wi-Fi ac and only has a single 5.8 GHz interface?
That is trivial to do via CapsMan . . . You might want to look again . . .
I have 4 AP's on CapsMan. Common security, and completely unique frequencies for each . . . .
(And yes, I tried it individually . . . CapsMan was far easier and less error prone. Standing up a new AP also became a trivial task - bring up in Cap mode, set ntp client, and schedules scripts (reboot notification) and done. (And that is a boiler plate script . . . )
7.24 also adds more features to the new "network" tab which simplifies capsman even more!
So now you can have:
1 common config
2 overrides based on the "label" (this sadly is still only via terminal)
config and override are separate for "wifi" and "radio".
But still no vlan support for wifi-qcom-ac 
CCR2004-16G-2S+
RouterOS v 7.24.1 has introduced a new error condition for me that was not there before
ipv6 ND error message automatic dns option advertising is not started, re-apply dns config
I have not researched how to re-apply dns config ... ?
Classic MikroTik update breaking something that worked perfectly before. Did you try rolling back to 7.23.3 to confirm it’s the upgrade?
Not Yet ... I want to researched this since its not a critical error
Under ipv6 settings I have Accept Router advertisements on interface=vlans and that solved a previouse problem I had that crashed my cable modem ... but this ND error is new since 7.24.1
My (by my i mean the ones i have on the deployment sites that the companies use) printers are working fine because they got ethernet ran to them because of all the reasons above, but ever since u run ethernet to the printer, most likely regardless of the circumstances, the printer will just work.
I personally don't have any issues with them and the context is not necessarely for this update/patch, it was just an offtopic conversation/rant 
OK I found the problem
Every interface above must have a corresponding:
/ipv6 nd prefix add interface=<same> prefix=<your /64>
So once applied the error goes away ...
Thanks for share...
Yes it looks like the "fix" was that update disables all ND entries and each will be enabled after reapplying 'advertise DNS' options in each of them. This way untouched entries would not be enabled.
If I remember correctly this appeared in 7.24...
It was not really an error, only a warning that the entry was keeping the behavior from 7.22 and earlier. And you can keep it like that or make the decision to swap to the new 7.23 behavior (that will then remove the warning). See the discussion at the end of this RC thread