The one thing I have learnt modding Civ 5 is, like everything else in life, you cannot please all of the people all of the time.
... add generalized changes mostly everyone wants/could do with ..."
There is no such thing.
If I'd written my DLL with everything hard-coded on, there would be exactly
zero people using it - as not even I play with everything that's in there.
... a single 'master' patch containing changes to all aspects of the game, whereas mods tend to focus on certain issues, and it wouldn't be a good idea to just clump them all together
Why? You will
never get consensus. The great thing about the mod system in Civ 5 is that you
can pick and choose which mods with which features you want.
The aim of this patch/thread is to provide the foundations (via a modded DLL) for other mods to build on - be that a small "tweak" mod, a revamp of a major aspect of game play (eg City State interactions), a total overhaul of the game mechanics (a la VEM/GEM/CEP) or a complete rewrite of the game as a Total Conversion (eg Ea). And by providing that common foundation to enable those mods to be used together (or on their own) as the player desires.
As such, the patch will contain only the DLL and any XML/SQL files to add required tables for the operation of the DLL and/or to update/add entries into existing tables (eg for hard-coded values being pushed into the Defines table). Additionally, with the exception of minor bug fixes (and there are remarkably few of those I have come across), everything by default will be "off" - it will be up to mods to switch on what they need. And as those mods are selected and enabled by the player there should be no unexpected behaviour caused by the DLL.
Exploits are not bugs, there may be solutions for them within the DLL but they will not be hard-coded as fixed - what if you want to play a few games of the research overflow exploit to see the effects for yourself?
Weak features are not bugs - there will not be "buffs" for them in the DLL. Neither are strong features bugs - similarly there will not be "nerfs" for them in the DLL.
What there will be in the DLL will be the tools to enable modders to efficiently "fix" those features as they see fit. If they need events that fire logically and consistently, and Lua API methods to access game core features, they should be added. Arbitrary decisions (eg, no negative happiness values for buildings) should be removed. New mechanics may be more efficiently implemented in C++ than Lua (although having written the river connection algorithms and a complete custom mission system for my Morindim civilization entirely in Lua, I remain to be convinced), in which case those mechanics can be added and then hooked up to the Lua events/api interface.
The huge advantage to expanding the existing Lua event/api interface rather than hard-coding some aspects into the DLL is that unknown future additions can be written in Lua. Back to the river connection algorithm - it's all in Lua with a couple of new events added into the C++ path-finding code to enable it. Want to write a mod to create city connections between airports? No problem, as the same events can be used for that. Want to create a Star Gate improvement and hook those into the city connection system? No problem, again the same events will suffice.
Think of the DLL as the gas, electric, water, sewerage, cable, etc connections and foundations for others to build upon.
Now, a problem with foundations is that nobody will buy them without show homes - so the patch will probably come with a few of those, in the form of example mods from the small tweaks to the full blown revamp (CSD). Do players have to use them - no.
As an example, my DLL currently has around 75 example mods (excluding the biggies of CSD and CivIV Diplo), but there are tens if not hundreds of thousands of possible mods that could be written using the new features in the DLL - most of which I can't even begin to imagine ... but others can.