There is a memory leak in 7.24 scheduled scripts (/system/script and /system/scheduler) - looks like all the script output (everything it outputs to its "invisible console") gets buffered in memory in RouterOS 7.24 and 7.24.1.
If you have scheduled/long-running scripts that do a lots of output and experience strange crashes, reboots or high memory usage in RouterOS 7.24/7.24.1, this might be the cause.
This has been reported to MikroTik (SUP-222576).
Some example?
Why not-interactive script must do some output?
oh boi...
I wonder when :set $variable [/some/command count-only where some_condition] will stop printing output...
That was promised long ago, but still not implemented...
I opened an issue for this a long time ago, and was told it will not change. Instead you should use:
:set variable [ :len [ /some/command/find where some_condition ] ]
Ok indeed that fixes it, thanks. But I think it is strange that [ ] does not redirect all output... for some things it works OK but for other things (like count_only) it does not.
Still waiting some concrete example.
Because is not simply
"/some/command count-only"
but
"/some/command PRINT count-only"... so.. PRINT... PRINT...
So...
right:
:set thisvar [:len [/ip firewall address-list find where list=mylist]]
wrong:
:set thisvar [/ip firewall address-list print count-only where list=mylist]
Then... in most cases when the list is very large... it's faster print...
everything goes back to printers in the end..
Well...
Let's use /ping as an example (for "Why not-interactive script must do some output?").
You can do something like :set p [/ping 192.0.2.1 count=5] that is very simple, short and readable, but produces console output as a side effect.
Or you can do this monstrosity:
:set p [/ping 192.0.2.1 count=5 as-value proplist=received]
:set p ([:pick $p ([:len $p]-1)]->"received")
which does the same thing, but produces no console output.
P.S. As another possible workaround I can mention :execute { the-output-producing-code } as-string inside the long-running loop (around the code that is run repeatedly and produces the output), however I don't think this will pass local variables (haven't tested though).
Of course, wrapping the entire script inside :execute {} as-string won't help, because then all the output will be buffered by :execute.
Why make it so complicated?
In Provisioning, instead of the “Create Dynamic Enabled” action,
use “Create Enabled.”
After that, you can configure each Capsman interface manually. And there’s no need to duplicate the work through Provisioning—it only makes sense to use it for configuration when deploying to at least 10 devices.
If you go this route:
Just dont create any provisioning rules 
Will work the same
But .... but ... how do you then micromanage your setup? 
Complicated? Seems pretty trivial from here . . . (And I do use "create enabled" . . . )
I have channel selections for each group I want to deploy, and configs using those - IE "5G-UNII3", etc.
The only difference in provisioning is inclusion of a MAC address and the config I want the AP on, and any extra slave configs.
(But yes, I have at times wondered about the apparent reduncdancy between WiFi and provisioning.)
the dynamic setup is better than hard-defining provisions by a mac address, its unnecessary hardcoding of stuff that should trivial via dynamic allocation.
Not for me.
With the MAC based provisioning I can perfectly define which channels get used where.
I know name based rules are also possible but MAC based worked out easier/better for me.
Besides, when a new AP needs to be added, it doesn't get any provisioning at all in my setups. So it can not interfere either.
Yet a other opinion offered as fact with zero justification, explanation, or much of anything useful.
It's pretty hard to take a lot of the "know it alls" here seriously when they can't (or wont) justify thier positions . . . .
Myself, I am of the mindset that if I don't control it directly and absolutely, that I really don't want it ...
That's pretty much exactly my case. Thanks to being in a very clean RF environment, I tend to do frequency "reuse" as we designed in mobile telephone systems . . . make sure any dupicated AP's can't hear much of each other. Here, I use the separate UNII 2A, 2C, and 3 band segments spread across the AP's . . . no overlap, allows wide channels, fast, stable, and can avoid most of the "Joe public AP" defaults. New AP? Pretty much 3 items to select to provision . . . MAC, and master/slave configs and done. (Or copy the desired rule and simply set the MAC . . . not sure how it could be any simpler . . . ).