I subscribe to the notion that no man should work for two bosses.
Likewise, no component should serve more than one purpose.
I say this because I need simplicity in what I code, to make life simple for me when I revisit my code.
Naming my components fully is important to avoid confusion, like btnConfirmLaunchWorldWarIII vs btnOkay.
When I use database components for specific purposes and in specific contexts (like Get today’s schedule for Update), I get the benefit of having my completion event know just what it has to do, without an if/then/else tree and the worry of having to keep yet another global variable to tie my app up in knots. (https://docs.google.com/document/d/1ccG7Nv_uRfRzGADaz17Jez9NjV0yBKqFTsuOo4iAixY/edit?usp=sharing)
Clock components are another matter, though. There is only one axis of time, and on that axis of time we can keep tables of deadlines to check for various actions. A single Clock1.Timer event can call a sequence of deadline checker procedures, each with its own deadline global variable. It can also service a queue of things to manage. (Changing Sprite in Blocks)
Notifiers are tempting to use, but they require name discipline to make clear how to respond to button choices, and to tie them to the Designer dialog and blocks that trigger them, otherwise they hang around as spinster orphans. Nested sub-Arrangements can make good notifiers, with the advantage of grouping confirmation buttons under the parent Arrangement umbrella of their initiators.