Then I showed up and started replacing the "find by extension" scheme with specific commands in configuration files to induce special behavior. On pretty much all of the modern text file formats, you need to use TEXTURE_LIT to specify your emissive texture, and once you use this command, you can use any suffix you want.
Why the change? I had three reasons:
Features by file naming convention is ugly. That's just an aesthetic decision by me, and most users find file extensions simpler, so if this was the only reason, I'd be a bit of a jerk.
File naming conventions don't grow over time. With file naming conventions, additional features would mean truly crazy conventions. Consider terrain files, where any terrain can be loaded with wrapped or clamped edges. (Wrapped edges are appropriate for repeating tiles of "land class" and clamped edges are appropriate for orthophotos.) We would end up with my_texture, my_texture_LIT, my_texture_wrapped, my_texture_wrapped_LIT, etc. What about the scale of the texture? What if we implement seasons? my_texture_2000_2000_wrapped_summer_LIT.png it is.*
By putting features in text files, we leave room for future expansion, and we have a lot more room to attach data to an image or control shading.
Probably most important: going to disk and loading lots of images is slow, so X-Plane loads images in the background while you fly. But checking the disk to see if my_texture_LIT exists is a disk operation too, and it is potentially one that we have to do immediately to understand our art assets. By having information about art assets in the text files and not file naming conventions, we can read one text file, rather than searching for all possible combinations of file extensions.
* Actually, Sergio and Austin were heading in that direction. Note that the names of the old ENV land classes were in the form CropCool0_000.dds. What are all the numbers? I don't know, but Sergio had a plan to use them to select lots of different textures. This scheme was never implemented.