Ah, thanks for that 
That was two weeks ago so I’m not too optimistic about getting results.
I believe the issue is caused by a change between 4.7 and 4.8. In 4.7, widgets would persist between level loads. However in 4.8, I think Epic changed this so that any widgets on the viewport get destroyed (GC’d) when changing levels.
The problem is caused by the fact that the main menu widget is added to the viewport after the call to Open Level… however the actual “level loading” doesn’t actually take place when Open Level is called. I think Open Level just queues up the level loading task, which then takes place some later (perhaps the next frame). Since the main menu widget has been added to the viewport before this occurs, it gets destroyed and removed, resulting in the black screen problem everyone has when you arrive back at the main menu level.
To solve the problem requires reworking the structure of the game instance and the way it handles widgets. Specifically, the main menu level should call an event on the game instance from its level blueprint to tell it that it has loaded and it is now safe to add the main menu widget to the viewport.
I understand why Epic changed this behaviour in 4.8, however I do think that this was overlooked and it has now created a “bug” of sorts. I think a better way to solve it would be for Epic to make a change in the UE4 source code; so that when a widget is added to the viewport AFTER calling Open Level, the widget is marked as “not to be gc’d” so the engine doesn’t remove and destroy it. Clearly the user’s intention is for said widget to appear on the screen in the new level otherwise they wouldn’t have added it to the viewport after calling Open Level. UE4 just doesn’t understand that “intention” but it should.
Thanks for this explanation. I ended up working around it by adding in a delay before loading the widget, but the event thing sounds good too.