This is to keep as much higher level logic out of these as possible. The presentation of the data should be a concern of the file system, not the data containers.
This is now being managed by the main file system class. The single lumps should only concern themselves with the actual data they manage, not with how the file system presents them to the outside.
The IWAD detection code was also switched to use a file system wrapper instead of looking at the single files directly.
This is not useful by itself but can be used for adding new features later, e.g. mod-wide compatibility settings or file specific lump replacement or injection.
It's "doom.id.doom1/2" instead of "doom.doom1/2" now.
The config file's content will be renamed and for lump filtering a fallback has been added - note that you cannot combine both naming schemes! The old one has to be considered deprecated now.
This also removes the duplicated content necessitated by the old naming scheme.
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
