While you wait for better answers, I’ll take a stab at convincing you to dial down your expectations for lifecycle events.
The way I think of it is that the only thing I can rely on is that the pairwise ones will be paired: I will not get two
ngOnInits in succession without an intervening
ngOnDestroy. Pretty much everything else I consider the framework’s domain. If it needs to evict things from cache and reconstruct them, that’s fine. If it wants to hide them and keep them around without a full teardown, OK.
The most important reason I approach things this way is that I figure anything else might work great in some environments, but not others. I don’t want to spend time chasing bugs that only occur on heavily-loaded FrobozzCo SUX-800 devices, especially when I don’t have one to test on.
So, I’m not sure exactly what you mean by “instruction messages”, but if as you say having them display twice is not desired, then I would manage that independently of component lifecycle: in a service provider, backed by device storage if we want to remember that we’ve already shown an onboarding message on a previous app run.