Repeated %_max_counter% fails

1 Select 10 tracks
2 Export using this config:

MC1 %_max_counter%,MC2 %_max_counter%,MC3 %_max_counter%.

Expected: MC1 10,MC2 10,MC3 10.
Observed: MC1 10,MC2 6,MC3 .


MC1 $get(mc),MC2 $get(mc),MC3 $get(mc).

This has not been tested in a loop and may suffer from the bug affecting variable access in a loop.

You have to take into account that the counter memory of %_max_counter%, when reading immediately after a loop, the counter is automatically set to zero ... I think so.
Obviously by your example, the counter runs into trouble when called without a previous loop, so it starts counting for itself.
There are two mte scripts attached, which demonstrates the behaviour of %_max_counter% in different coding situations.
__Export.MaxCounter.Anomalie.1.mte (529 Bytes)__Export.MaxCounter.Anomalie.2.mte (591 Bytes)


__Export.MaxCounter.Anomalie.1.mte (529 Bytes)

__Export.MaxCounter.Anomalie.2.mte (591 Bytes)

Thanks D, but my example's calls all are with a previous loop. The failing ones are without an immediately preceding loop, but this should not affect the result. My usage accords with:
%_max_counter% Maximum value of counter of the last closed loop.

The program behaviour does not. That's why I suggest there is a bug - in program or Help.