As a workaround, I would recommend taking full control of the view switching instead of relying on the built-in Day / Week / Month buttons. In the new Calendar widget, these buttons do not trigger the view range change microflow, so this approach tends to know be more stable and predictable.
The first step is to assign a custom CSS class to the Calendar widget (for example custom-calendar). Using this class, you can hide the default Day / Week / Month buttons via custom CSS. Since the widget is based on FullCalendar, this works reliably and only affects this specific calendar, not the rest of the application.
Next, add your own Day / Week / Month buttons to the page. These buttons can call a microflow that updates the start and end dates on your non-persistable entity and refreshes the calendar datasource. This gives you full control over when and how much data is retrieved, which is especially useful for large datasets.
Overall, hiding the default buttons with CSS and replacing them with your own microflow-driven controls is currently the cleanest and most reliable workaround for this limitation.
This is a limitation of the new Calendar widget.
In the new version, the “On view range change” microflow is only triggered when the actual date range changes (Previous / Next / Today). Switching between Day, Week, or Month does not trigger this microflow, because the widget does not treat view changes as a range change.
So your approach is correct, but the widget currently does not support this use case. The only workaround is to use custom Day/Week/Month buttons or retrieve a broader range by default.
This is expected behavior, not a configuration issue.