In my tests (most basic scenario that was possible), it just works.
Of course... You need to accomplish the other requirements of HW-OffLoad.
The guys that used to create a bridge for each vlan that existed... go crazy on that.
Is there a specific reason why dtim-period=3 is being changed in the default configuration after so many years of using dtim-period=1?
Power saving...
so is that set global and not dtim=1 for 2.4g and dtim=3 for 5g. 6g?
Yes of course. But this is a known fact for long time. Why introduce it in defconf only now? I suspect some compatibility improvement or something.
DHCP Circuit-ID and Remote-ID - Display Inconsistent Behavior between generated locally or received remotely
I've noticed that when the Circuit-ID and Remote-ID attributes are generated locally, RouterOS displays them in hexadecimal format.
However, when the attributes have already been generated from another network device, RouterOS displays them as ASCII.
I created the case SUP-217843 on Jira.
If anyone else has the same pain, please manifest.
Edit:
I mistakenly assumed that the hexadecimal/ascii aspect was related to this attribute being generated locally or being pre-loaded from the DHCP packet.
I expanded the tests and found that the same equipment that in v7.22.3 displayed the Circuit-IDs generated by the OLT in ASCII, after being updated to 7.23.1, started displaying the same Circuit-IDs in hexadecimal.
Bravo... Excellent deduction... 
What great news! A feature lost in the v6 to v7 transition has finally been fixed!
Old-time "industry standard" has been 1 - and there are many warnings about how multicast traffic (if applicable) can suffer from increasing it.
What comes to power saving, wifi6 and newer devices might be less affected by this value as wifi6 has target wake time algoritm for managing power saving (this obviously does not apply to client devices which do not support wifi6).
...and if one wishes to be more conservative value of 2 can be used as well.
Current uptime is 6 hours, no (false) radar events. Could this have helped!?
Is this what I think it is? Dynamic Arp Inspection support? that's why the previous beta it has DHCP snooping database was added?
It would be helpful to have some reference to the manufacturer release notes or version number.
I haven't had a chance to test this version yet, but since I'm pretty sure this came about as a response to my bug report (see [Bug Workaround] BGP Route Reflector corrupting NLRI for EVPN Prefix Routes for more details), I believe this only handles forwarding Type-5 routes, not generating or installing them, since this is listed as a BGP change and not an EVPN change. I'll respond with more detail once I've had a chance to test, which may not be for a few days.
I have no idea at all. I have not encountered problems related to this. My devices facing the ISPs don't accept RA (all PPPoE), and I am too lazy to modify the CHR setups for testing.
*) x86 - fixed IRQ displaying per CPU on Intel 700 series NIC;
may you elaborate e bit more?
thanks
This is only to fix RR issue and display, nothing more.
I'm sure that note in the release notes is definitely related to your case!
I was imagining how much time you spent delving into bits with packet capture to infer the reuse of MPLS functions in VXLan VNIs. Congratulations!
But now, given your explanation, I'm certain that MikroTik has everything it needs to implement EVPN Route Type-5 over VXLan. I understand it's basically a matter of dynamic linking between VNIs and VRFs.
I hope mac-vrf is in the horizon 
and VTI IPsec and I couldn't ask for more haha
humm... I fell they will try to bandaid this with multi-bridge.
"dedicate a bridge to this... is almost the same as mac-vrf."
To be fair, I did not study the prestera resources to check if mac-vrf fits there.
But I don't imagine any reasons for not doing.
There are any efforts on EVPN Route Type-5 with VXLan to be implemented on the forwarding ?