Enabled Subsystem does not reliably disable

The Simulink model shown in the screenshot does not behave as I expect, and I would like to understand the reason.

All blocks are on default settings, except:

• Gain: 1/pi
• Compare To Constant: operator >=, constant value 1.0
• Logical Operator: XOR
• (Scope: two inputs, line markers)

Note that the Compare To Constant block has Zero-crossing (ZC) detection enabled by default. The Enabled Subsystem consists of one input port directly connected to the output port.

All solver settings are at default values. The solver is auto(VariableStepDiscrete). I only change the StopTime of the simulation (see below).

Expected behavior

The enabled subsystem should be enabled for exactly one time point (in major time step) and "sample and hold" the value of its input (the scaled clock signal).

This should occur when the scaled clock signal reaches the threshold value of 1.0 (but not later than that, thanks to zero-crossing detection).

The sampled and held value (see Display block) should be 1.0 (sampled at time t=pi).

Observed behavior

Sometimes the result (= sampled and held value at the end of the simulation) is larger than expected. The scope screenshot (lower half) shows that the enabled subsystem seems to be enabled for two time points (instead of one). In the first time point (at t=pi) it copies a value of 1.0 to its output, in the subsequent second time point a value of approx. 1.025, which is then held until the end of the simulation.

Whether the problem occurs, weirdly depends on the StopTime. Some examples:

• For these values of StopTime the problem occurs: 4.00001, 8, 9, 10.1, 11, 13.
• For these values everything works fine: 4, 6, 7, 10, 12.

My analysis so far

When the problem occurs, Simulink has placed two time points at the zero-crossing, one just before and one just after the zero-crossing. When the problem doesn't occur, there are three time points close to the zero-crossing (one just before, two just after the ZC).

Although the XOR block output is correctly true only for one time point (right hand side of the zero-crossing, see upper half of the scope screenshot), the final output of the enabled subsystem seems to always be equal to the value of its input sampled one time point later (that is: when the XOR has dropped to false again). That is not a problem if that time point is the third of 3 close to the ZC, but it produces a wrong result if that time point is much later than the ZC.

So I wonder why Simulink sometimes uses 3 time points at a ZC (good), but sometimes only 2 (bad). Any hints or explanations welcome why Simulink behaves like this and/or why it should(n't).

Some more notes

1. I know the expected behavior could be implemented differently. That's not the point. This is a minimal example. In my opinion it should not behave the way it does.
2. I'm unsure about the correct/official wording: What I mean by "time point" are the elements of "tout". Usually I refer to them as major time steps, but maybe that's wrong as they're points in time, not steps. (?)
3. My maybe related (and unfortunately still unanswered) question about zero-crossings and the number of time steps/points taken by Simulink: https://de.mathworks.com/matlabcentral/answers/553960-number-of-necessary-time-steps-to-handle-a-zero-crossing