I would use the 1.70, but you were still using the broader things that don't make sense (to you) philosophy; I brought up a lot more than just colored icons and to not make this about CPP specifically, I just tossed out some examples from it.
My grandfather used to tell me that if I didn't want to hear opinions I didn't agree with or like then I should avoid asking for them.
I stated I was just using your particular project as an example because with it there would be a common frame of reference for you to understand my opinion. You asked "why do you prefer having options or not having options when you installing game modifications," which usually entails giving examples. You even open with this thread by using your own project as the basis for why you are seeking opinions on the subject.
"I would really want to know your reasons and experiences" should probably be rewritten to say "as long as you don't mention the exact project, which happens to be mine, that I am using to start the discussion". Apparently you are willing to accept any and all examples other than ones that mention it and are then, as always, ready to shoo off anyone who does as "not understanding", flaming, spamming, and then direct them to a "proper thread". In other words, you are saying that any opinion contrary to your own about your own is invalid.
I am in the proper thread: you asked for what people prefer and why and I responded, on topic, with examples why. If you don't want to hear it, don't ask. If numerous threads of yours seem to devolve into what you see as a flame fest, you should probably take note on what components they all have in common. I am not one of those components.
The Infinity Engine setup is a whole different animal and, as MagicalMaster stated, any changes are confined to that specific campaign. An all-in-one patch project that implements global changes is fine when applied to a specific module / campaign going forward and when you are building with it in mind. The problems start occurring when it's applications alter previously made modules that were not built with it in mind. Those builders worked within the constrains of the underlying system as it existed when they built it. This leads to having to make adjustment within the actual module to compensate for the changes the all in one made.
If you have the official campaign and the all-in-one, you know exactly what each has implemented and can specifically tailor the all-in-one to fit the module, balance, and make those components work together. Overlaying an all-in-one over a specific existing module means going back into the module and tailoring it to fit. This all works well and the Q Campaigns are a perfect example of this; it works out of the box.
Conversley, heaping Project Q on top of other existing modules means adjusting each module individually to fit. This is easier within Q's scope because Q is primarily visual resources, but an all-in-one that cuts deep into the inner workings, scripts, and fundamental behaviors is less appealing for global implementation.
Then again, "this thread is not *directly* about [Project Q]" so it looks like I've gone an done it again. I'll have to work better on giving examples without actually using examples.
It's spam to talk about the exact topic you made this thread to talk about?
Only on Shadooow's threads. (See paragraphs 4 and 5.)