Well, firstly I disagree with your "3 Categories" - the most common category I think is this:

"I think it would be awesome if I could just do this one, particular, extra thing, which Quake currently doesn't do, which would really get me excited about making new stuff for Quake."

These people have 99% of what they want in their engine of choice, and are just wondering if they can convince someone to implement that extra 1% of stuff.

They don't want to make a massive Q3 total conversion, or a HL total conversion, they just want to carry on making Quake stuff but with a little extra "something".

As for the second part of your post, I agree with the basic gist of it. An engine request has pretty much zero credibility unless the mapper has thrown something together to prove that he can talk the talk and walk the walk, and a programmer takes a look at it and thinks "yes this rather nifty content that actually exists would really benefit from that one extra thing that the creator would humbly like". 

I'll take the bait.

I am frustrated with the music limitations in id1. I need the ability to play a music track with a unique name.

https://github.com/quake-mapping-community/quake-engine-features-wish-list/issues/5 

Feasible and "correct":
- Add/improve support for X base file format (mdl, iqm, midi, mp3)?
- Add support for a Y way of incrementaly adding mods without having to fuse and recompile a few mods together
- Support for Z basic feature in CSQC

Infeasible and not quite a fit:
- Add support for X flashy effects, shaders, physics
- Add models or Y mapping capabilities for vanilla quake
- Support for Z game engine features in Quake

I think the infeasibility lies on whether the feature should be something particular to a sourceport or something that can improve/add to quake engine across all engines (such as tooling or better control over existing features). Or even extending existing features to allow basic game features such as an user interface. But when you go into the are of flashy effects, models or brushes you should look into engines or mods that support that.
I know it can be a gray area sometimes but I think the "vanilla" mindset should overcome the desire to add that-new-thing-that-engine-or-game-has.
Take a look at Doom foe example. ZDoom is treated as the standard, but it won't support advanced lighting effects, 3d models, volumetric fog or state-of-the-art particles technology, or shaders or anything. GZDoom on the other hand support a number of new features, so users are free to pick and choose.

I think we should think more of:
1) Make easier and more attractive at some level for new modders and mappers to use Qengines
2) Make it compatible across all engines, trying to standardize as much as possible implementations and specs
3) Don't bloat up the "base" engine features with stuff

That's my opinion though, you're all free to disagree. 

My personal wishlist leans toward standardized features like:

- lifting dated memory/count/range limitations
- HUD/menu setup and flashy effects accessible with API expansion (e. g. additional params for particle generation style)
- water transparency, splat decals can change the gameplay, should be mod-controlled && map-controlled 

How about this?

You could open the console and do something like
-load pak99.pak
or a pk3
maybe even do like
-load pak99.pak/progs_for_mod_testing/knight.mdl
to replace an mdl already being used
Maybe even do something like
../mymod/progs/some.mdl
Imagine a quick model replacing thing to cut down on a bit of time.
Just fire up your engine and load a folde or pak containing a model and then start a map having an entity with that model. 

+1 for that. The Quoth Map Paks basically work on that principle - the map plus all the resources are stored in a single pak file.

In order to make it work without engine support I wrote a batch file that renames the file to pak3.pak, but the idea that engine support could make the method slicker was something I had in mind. Dynamically swapping a map pack in/out would be nice, or just having a GUI to select the pak files. 

finally for the firs time in my life i have suggested a valid/appropriate suggestion.
better work on it and suggest better ideas...or make it myself. 

The chance to create colored lights (.lit) in game, like Darkplaces do with RT lights. Same for fog, rain etc.. 

http://www.celephais.net/board/view_thread.php?id=60497

But anyway would this be possible? 

q3bsp + lightmap lightstyles exists (fbsp).

DakPlaces doesn't support it but I think FTE does. 

Not what I mean: I mean creating them DURING game (darkplaces can do it for RTlights, but not .lit)