Directly opening a modified map asset of a streaming sublevel does not always force it to be reloaded (inconsistent with other map open behaviors)

When the level currently being edited has unsaved changes and the user opens a new one, the Editor asks if the changes should be saved. If the user answers negatively, the level asset is reverted to its last saved state from disk. This is true and expected even when reopening the current level itself.

If the current level has streaming sublevels with unsaved changes, opening another unrelated level also prompts to save changes to the streaming sublevels. Those changes are also lost and reverted if the user does not choose to save.

Now, consider a situation where the current level has a streaming level with unsaved changes, and the user opens that sublevel's asset directly. Once again, the Editor prompts to save the sublevel's changes. However, when the user answers negatively, the behavior is inconsistent: most times (but not every time), the sublevel asset does not get reverted/reloaded, all its changes are retained. If the user then reopens the same sublevel asset again, only then the asset is reloaded with all changes reverted. The inconsistent behavior can lead a user to accidentaly keep or discard changes when the opposite was desired.

1. Create a new level "MySubLevel" from the "Empty Level" template (or directly from the Content Browser)

1.1. Place a Cone at (0,0,50) with no rotation (pointing up)

1.2. Save

2. Create a new level "MyPersistentLevel" from the "Basic" Template

2.1. Add "MySubLevel" as a sublevel

2.2. Save both levels

3. While editing "MyPersistentLevel", rotate the cone from "MySublevel" 90 degrees (e.g. so that it points left or right)

4. Open "MySubLevel" (through File – Recent Levels or by double-clicking in the Content Browser), but do not save when asked

4.1. Note that the sublevel asset is still modified in the Content Browser, and that the cone retained its rotation

5. Reopen "MySubLevel"

5.1. Note that the sublevel asset is reloaded, losing its modification status, and that the cone has reverted to its original rotation

Note: In some rare tests, the issue did not occur on the first attempt, only on the second and others

Note: No difference if the sublevel streaming method is "blueprint" or "always loaded"

Note: No repro when using instanced levels