There may be a good reason that these are hard coded but, if possible, it would be good if the sound environments hard-coded in s_environment.cpp could be moved to reverbs.txt in gzdoom.pk3
So, getting that changed would be the most obvious/immediate advantage/convenience thing for an end user, but it strikes me as odd that some sound environments are in reverbs.txt and others are tucked away in the code. So, (like I said) unless there is a good reason for them to remain hard-coded, it would be useful for them to... well, not be.
My guess is the reason why these aren't exported already is because they might be doing something internally with the setup in the reverb engine that can't yet be replicated with reverbs.txt - but I could be wrong, and without a deep-dive into the source code I couldn't say for sure. Historically that has been what's what when something stays hardcoded for this long, though.
I noticed that most of them seem to be "base environments". i.e. a lot of them seem to be basic "this is the default for this style of environment" that others might then be based off/modify. A lot of them have whole number first parameters - e.g. "Alley" 14 0. (I don't know if that's relevant.) However, it's not all of them, so I'm just stabbing in the dark really. As you said, they have remained hard-coded for a long time so, presumably, there was a reason they weren't extracted, and perhaps that reason is still valid.
To help the editing side of things, I just posted a very basic resource file in the UDB thread that provides number definitions for the hard-coded environments. So, that can be loaded to get UDB to list the hard-coded entries. It doesn't, of course, replace them, and the file is only there as an editing resource., but at least it means that all the possible pre-defined entries are now listed in UDB - and there are some useful ones in there too.
From what I know, there's a couple parts to the hard-coded environments to be cognizant of (whether or not they're ultimately moved to reverbs.txt).
For one, the hard-coded/built-in environments aren't allowed to be overridden by mods (as determined by ID, not name). Attempts to do so are silently ignored. There would need to be special handling for definitions in the reverbs.txt loaded from gzdoom.pk3 to make them non-overridable by future definitions in mods.
Secondly, there's a special "DSP Water" entry (ID 255 255, or 0xffff) that sets a "SoftwareWater" flag, which invokes special behavior. When used, it behaves as if the listener is underwater, using the Underwater reverb effect with the lower pitch and low-pass filter applied, for when the player isn't actually underwater but should sound like it. It's actual definition is ignored as a result. Since custom reverbs can't set this flag, and built-in environments can't be overridden, this can be handled by ID checks rather than that special flag.
So from my perspective, I don't see an issue moving them to reverbs.txt in gzdoom.pk3, as long as the definitions in gzdoom.pk3 can be protected somehow, while still allowing mods to override definitions in other mods.
