ZDoom

A strange observation I had when toying with "Episode = clear" to illustrate an unrelated bug in PrBoom+/UMAPINFO 2.5.1.7 - if "Episode = clear" is not present in this example UMAPINFO lump, the episode listing lists the episodes in the order they are defined (i.e.: "Main Attraction" shows up before "Extra Levels"). If "Episode = clear" is present, the episodes are not listed in the order they're defined (i.e.: "Extra Levels" shows up before "Main Attraction"). In either case the episode listings presented still take you to the appropriate starting map, but it's weird that this is happening at all. I'm not sure what the rhyme or reason behind the ordering when the episode listing is cleared actually is; I tried redefining the first episode from:
to: or: as I figured it might be an alphabetical-order thing, but in neither case did this reassert the correct positioning for "Main Attraction"; it still gets listed after "Extra Levels", despite "Main Attraction" starting at MAP01 and "Extra Levels" starting at MAP11.

Here is a ZIP file containing three WADs. Specifically:

• UMAPINFOBugExample.wad: The base WAD for UMAPINFO mod I am making, stripped down to the barest essentials for illustrating some tickets. Use Doom II for the IWAD. This will illustrate the episode listing in the intended order.
• UMAPINFOBugExampleAddon_EpisodeEqualsClear.wad: A small WAD containing a copy of the above WAD's UMAPINFO, but with "episode = clear" before any new episode definitions. To use it, load it after "UMAPINFOBugExample.wad" in the load order. This will illustrate the episode listing showing the wrong order when "episode = clear" is present.

SIGIL_UMAPINFO_full.wad is also in this ZIP file; it is not relevant to this bug report, but is relevant to other ones (I'm using the same ZIP file for like five separate reports, if it wasn't clear by now).

"Episode = clear" removes the current episode from the list of all episode. The next episode definition is added at the end of this list.
As a workaround, it's possible to clear every episode before redefining it. The problem is such trick won't work without this fix.
As for real solution, I'm not quite sure how we can preserve initial episode order.

That doesn't seem correct; going by the spec, it seems like it's not supposed to remove the current episode from the list, but rather clear the list out entirely so that only ones defined after that go in. Both episodes in the listing would be defined after "episode=clear" is parsed.

Yes, it was incorrectly implemented.