Every occurrence of an empty variable is on the third line.
Script Code:
{
:local func do={ :put “txt $domainName” }
[$func domainName=123]
[$func domainName=223]
}
{
:local func do={ :return "txt $domainName" }
:put [$func domainName=123]
:put [$func domainName=223]
:put [$func domainName=323]
:put [$func domainName=423]
}
{
:local func ":put \"txt \$domainName\""
:local domainName 123
[:parse ":local domainName $domainName ; $func"]
:local domainName 223
[:parse ":local domainName $domainName ; $func"]
:local domainName 323
[:parse ":local domainName $domainName ; $func"]
:local domainName 423
[:parse ":local domainName $domainName ; $func"]
}
{
:local func do={ :return {"domainName"="txt $domainName";"another"="text string"} }
:put ([$func domainName="123"]->"domainName")
:put ([$func domainName="223"]->"domainName")
:put ([$func domainName="666"]->"another")
}
The “subshell” backets aren’t strictly needed in the code block. So this does what you’d expect:
{
:local func do={ :put “txt $domainName”}
$func domainName=123
$func domainName=223
}
or even this works – it’s the last one can’t be subshell I think…
{
:local func do={ :put “txt $domainName” }
[$func domainName=123]
$func domainName=223
}
In theory, the [$func domainName=223] should be harmless … but the does return a value of the inner command, which in the case of a :put, whose return is string. Somehow the subshell is calling the contained function again when exiting the block. That doesn’t seem right, but you don’t need the subshell operators either.
I’m updating my post with more examples and final description, you anticipated me 
There is no need to discuss whether is necessary.
Even for a function without a return value, adding is acceptable.
It is similar to a regular function where the return value is either 0 or empty.
The actual problem is that no matter how many lines are executed,
after the second execution, there will be a phantom execution with empty parameters.
This is a bug in the RouterOS script interpreter itself.
Since it has been reproduced, MikroTik can fix it.
I believe this issue will be resolved in version 7.10.3/7.11 or possibly in future versions like 7.12.
Otherwise, it could be exploited by someone as a buffer overflow to execute attack code.
Surely if someone has access to write new scripts in the RouterBOARD they will worry about causing buffer overflows on the machine they already have under control…
Glad MT fixing it. Not sure this a new issue however – pretty sureI 've run into this issue myself at some point (using for a fn call inside a block as the only line). But I still think are an unnecessary if one is pandantic – but was not an argument to not fix it Now totally not sure the security argument here… it may not be correct behavior, but it’s not like some code gets access to memory/etc as a result of it.
Again, not to argue it's not a bug... But also I just think it's good practice to always return a value (even if it's [:nothing]) from a function. So @rextended's example just seems "safer" approach.
( and if is needed, on the last example is returned one array of return values… )
No, they won’t fix it. We reported a long time ago that when a function is executed twice in a subshell, it is executed three times. Woz and now there. Mikrotik doesn’t know how to fix the error.
[$myFunc]
[$myFunc]
Yes, I agree with Amm0, there is no “third time error” without a shell.
$myFunc
$myFunc
This is the name of this case I liked: [$BUGOS] 
already confirm in SUP-122073, will be fix soon.