As the above report mentioned,
I suspected that in 2.8, the redraw stopped because of the loss of context, where the context.area returns None.
But after second thoughts, that doesn't make any sense. They both used window_manager.event_timer_add() and seems to use it to trigger the tag_redraw().
If window change would return None since 2013, then screencasekey addon shouldn't be able to sustain its redraw over time in blender 2.79, but it does sustain it.
There are no differences that I can perceive and understand between screencasekey for 2.79 and shortcut Vur for 2.8 on how they achieved the repeated redraw over time, and yet they behave differently in two blender versions.
There must be something different between blender 2.79 & 2.8 that caused this discrepancy.
I'm not sure what type of problem this is or what is wrong, but I hope blender 2.8 can behave in the same way as 2.79 in this specific case.
Exact Description of this issue
Win 10 Pro,
AMD 1700x w 32GB & 1080
2.8 positive symptom with Shortcut VUR addon and with my own script.
2.79 with screencast key addon
Short description of error
Note: I don't think this is a problem on the Addon part since screencastkeys on 2.79 used the exact same method to achieve timely redraw for the on-screen messages.
Without window layout change, both addons worked correctly, the on-screen input message disappears after a short time.
After window layout change, context.area within MODAL method returns None, and on-screen input messages would not refresh until triggered by another input.
Returning to previous window layout won't fix the issue.
The event 'TIMER' is still triggered consistently, the screen though, would not redraw when the 'TIMER' event hits.
Exact steps for others to reproduce the error
1, Enable said addons in their corresponding version of Blender,
2, Start the modal operator with the button in the Side panel
3, Observe as the input messages disappear
4, Maximize the window, or change to a different layout
5, Notice the messages do not disappear unless new input such as MouseWheelScroll happens, and it would timely redraw for a second or two, and stop again.
According to the report here, context loss is a designed behavior of modal operator.
The fact it worked in 2.7 across different windows seems to be a glitch. But in the case of casting inputs from modal operator, it did work better.
2.8 version of the screencastkeys had defined a method to find the active window/area for the script to work when maximizing a window, but upon workspace change, the display will disappear completely.