I thought a bit more and ended up at the conclusion that instead of creating a new generic 'Then' or 'Next' system condition (that doesn't mean much), it would be clearer if it was a special condition from the LocalStorage object, or the Pathfinding behavior kept it's 'On path found' condition and so on. 'On path found' describes a lot better what it does than a generic word like 'Next'. The same for something like 'On requested data ready' for the LocalStorage, it's a lot more meaningful.
My proposal is to create a new type of event, a kind of "scoped trigger" (in the sense of a trigger which acts depending on scope). It would have a different icon (like the different arrows for regular trigger and loop conditions) to differentiate it from the rest.
When placed below an event, it should automatically recognize the scope and act only in the scope of the previous event. In the case of the LocalStorage it could be an "On all completed" trigger for the previous 'request data' actions from the event above. For the Pathfinding behavior it could act as a regular trigger, but only fire for the previous 'Find Path' action from the event above. This allows to make contained triggers.
Exploring the possibilities, this "scoped trigger" could act locally only when placed as a sub-event, triggering only from the actions in the scope of it's parent event. This opens some new possibilities: when placed as a top-level-event it could be triggered by any related event, responding to any call throughout the event sheet. So it could be more versatile acting both as a local trigger (as a sub-event) or global (as a top-level-event) depending on scope. This new type of trigger would even allow local functions, that could be really handy.
Now focusing on the LocalStorage, I believe it would be possible to give options to use it both synchronously or asynchronously. For really small data like simple variables (probably the most common use), a synchronous storage works very well with a small performance impact, but compensates greatly with it's easiness of use. For big data like long strings, an asynchronous storage is better because it doesn't stall the whole event chain while reading or writing, but it complicates a lot the use of events.
So why not keep both and let the user choose depending on the circumstance or data type?
The LocalStorage could have a traditional set action with a get expression that works synchronously for small data, stalling the event execution until it's complete but requiring less events (like WebStorage did). And also asynchronous events like a 'Request data' action and a 'On requested data ready' "scoped trigger" for when big data is necessary. This would make it possible to use both simultaneously, getting the benefit of both systems depending on the data you are dealing with. Like using synchronous events for simple values like lives and scores, and using asynchronous events for long data like dialogs or level data for custom level editors.
*I'm assuming that in theory asynchronous events take the same amount of time to complete than synchronous, so it's possible to make synchronous events out of an underlying asynchronous system. If not then the change to an asynchronous system sounds much worst than I thought.