Thank you for this detailed comment, I try to give an answer from my perspective.
What everybody wants from OpenTTD is to be a reliable, long-living, stable program. A second thing that we want is backwards compatibility, it can read files that are more than a decade old, all your old savegames still work today. To a developer, that means the program must be maintainable and robustly built. You want the fundamentally proper solution to a problem, since that is the best way to ensure stability and reliability.
This is a very senseful goal.
There is another thing that we want, namely we want the program to be extendible. If someone finds a proper solution to daylength eg, it should be added.
In my experience as a patch developer, such clear statements are very important. What you say here is basically, "it is senseful to spend time on this problem, because a proper solution would be accepted." (at least in your personal opinion, having your disclaimer above in mind). As a patch developer, such a statement gives a lot of motivation for spending the work needed to improve a 90-percent-solution to a 100-percent-solution.
And such a statement is not a matter of course - because the fact that a feature never goes to trunk can easily mean that the dev-opinion is that the very basic idea of the feature is not liked. If devs say "day-length does not fit into the game, regardless of the implementation", then spending time to make a patch ready for trunk in a technical sense would simply be wasted.
This also points to fundamentally correct solutions, since these capture the core mechanism well, and are most likely to be a stable foundation to build on in the future.
Given my experience as a software developer, I would say that the question, about which aspect of the implementation you talk is quite important here. For example: If you miss something important in a day-length-patch, then you are in danger of breaking important things. If you have some problem in the implementation of a new landscape generator, then this is an isolated problem because you always have the choice to use the old one.
So, I think the question "what could go wrong if we would miss something" is a quite important question about patches.
- The number of developers decreased from ~10 to ~1 (and I count for around 0.1 at most)
- For emphasis, there is ~1 developer, doing everything in his spare time only.
So, we really talk about exactly one human person?
No wonder things get slow, or announcements fall off the todo-list. I agree it looks sloppy, but with so many things to do, and so little man-power, what would you expect?
The topic here is the new features that seem to stick around in patches forever.
It is true we are not well organised in reviewing patches.
The thing is: How did the devs become devs? Probably, by implementing patches, that were eventually added to trunk, and at some time, they were asked wether they want to become devs.
But if no one has the time to review patches, people joining the community or starting to write patches don't have the chance to follow this path.
The biggest problem with almost all of them however, is that they're, frankly, duct-tape and ply-wood. Patches like signals on bridges extend on a barely existing foundation, to the point that it's about to collapse under its own weight. It's fine for prototyping, but not a robust solution that will be extendible into the next decade to whatever we invent in 10 years from now.
I understand what you mean. Maybe a clear communication about the state and perspective for patches would help? (maybe as a Wiki-page maintained by the devs?)
Getting back to the day-length example: The topic exists for years now. Probably, solutions were more or less inspected by devs or other persons. And given what I read here, these solutions always were considered to have severe problems that make an addition to trunk impossible.
If there would be a Wiki page with a table of currently existing patches, where a dev reviewing a patch enters a short comment, something like "coding style ok, but there is a severe conceptiual problem concerning ..., see forum post (... link here ...)" then this wouldn't be too much extra effort compared to the pure review, but would add a lot of transparency.
"solid foundation" means a year or more work before you get to the point of adding the feature.
As I wrote above, there is a difference between spending that time given a basic committment "this feature is liked", or spending this time in a situation were you don't know wether the feature is liked at all.
It may look like a bad policy, and we should accept less finished patches.
As you wrote above, there are no small problems left. So, I personally in my patches tried to solve some of the big ones.
More height levels went to trunk after about 6 years of development (with some misunderstandings shortly afterwards, because devs expected me to address some problems, which I didn't realized).
The timetable improvement patch  (lives as a patch since December 2012) changes timetable handling in a quite fundamental way.
The river generation patch  (lives as a patch since December 2014) does a little bit refactoring of map generation window to support the concept of different river generators, and then adds a new river generator.
I really tried to stick to the coding style, and comment things, but in the end these patches are from my perspective in a state like
- most of the work is done, they do what I expect for my games
- there may of course be tasks left, e.g. I never play multiplayer, and I currently don't remember exactly wether I addressed the conversion of savegames with old timetable information properly (to mention just two aspects that may be relevant concerning the timetable patch)
- they both have quite a lot of code
Now, I as a patch developer have the situation
- probably, no one has the time to review 4000+ lines of code (in the case of the river generator) line-by-line
- in the case of the timetable improvement patch, it is not even clear wether the idea itself would be liked at all
- concerning the river generator, at least I assume that people wouldn't object against the idea of having a new river generator
- I don't exactly have too much time in real life either
So, what should or can I do with these patches?
Given there are many other tasks as well in real life, my answer so far is simply, I let them live as patches, maybe once or twice a year I have a look wether they still apply to trunk, but I don't spend more time for them.
So yes, you can add todays gimmicks in duct-tape and ply-wood,
Actually, in my opinion the improvements for OpenTTD that would make sense (at least for me) are not gimmicks, but improvements for game mechanics itself. That's the reason why I never started with small patches, but tried to address big tasks.
The 1,000,000 dollar question is, how do we turn around the tide??
Unfortunately, I don't have the answer.
IMHO, you as devs should ask yourself the question, who can actually be considered active, and who actually already retired from the project. Depending on the answer to this question, maybe to some extent you should pass things to the next generation.
I mean it is nice to have a game with such a stable codebase, and such a sense for code quality. But if development stops because the devs that are considered to be able to produce high-quality code retired, then actually the question arises why other people shouldn't have their chance to improve the project either?
In an association I am a member in, it is often said that whoever invests time and work for setting up something (e.g. some event) decides *how* it is done.
And sometimes I think, that a little bit more of this spirit would be quite a benefit for OpenTTD.