If your referring to the Wiki Changelog saying "Warning: Don't update to this in important worlds, as it is a beta and could break things.", Then that is not Greg's personal opinion on the matter, I Personally added that.
IC2 is still in development stage, and isn't very stable itself, as seen by it repeatedly breaking the API, and hence Gregtech. For all I know, Greg figures his mod is stable. I just would rather be safe then sorry until IC2 comes out with a Stable Build.
no but if one follows the forum links and then reads on, one sees greg essentially begging for someone anyone to test the update and give some feedback. that screams danger will robinson. and thats not even counting the number of times he has commented on the need to fix something because someone elses code is broken, or just plain changed and added something in a small timespan.
it all adds up to there's gotta be instability somewhere, but the real icing on the flag is when a simple test can turn up it's not fully functional or stable. as noted 2.90h has the configs(which he nted got reworked for the ore dict and swapped about mind you) with some issues like uu2bauxite= true not working no matter what it's set to, an osmium uu recipe not in the configs. the api change which renamed isquantumchest() method to isdigitalchest() which breaks anyone not on the most recent change(which is buried in the thread and seemingly nowhere else) and other issues.
i consider his configs to be one of his most praiseworthy elements, as it can be a lot of work to support that much additional optional alteration, and he has quite a lot of optional. when even that is broken you know you are gonna have a bad time.
so i'd say your call just synopsizes everything said in many more words presently.
as to his mods goals. well that treads into the weird land of mod author goals and vision vs the end user or consumers desires. ideally one hell of a lot of mods would compartmentalize what they do quite a bit more than they do so end users could be quite a bit more specific about their mix and matching. ideally forge would also have a means of taking their recipes as a default suggestion, and proviso a second layer flatfile that exposed all the items/blocks added by all loaded mods and allow overriding individual mod recipe configs from there.
these things however are not necessarily in the mod authors interest. compartmentalization for example has the impact of using more block and/or itemids than conglomerate giant mods, at least insofar as what i've seen, due to the way those things get handled. it would also add more nuisance code for interactions between specific mods as the number of cases to check for would be multiplicatively higher(like paying for dinner with pennies instead of dollar bills, the values the same, but the bulkiness and number of individual operations ..).
end users looking to customize their experience the way they want it, and the mod authors looking to set up a system supporting their own vision which limits customizations fine control. me, i'd yank the quantumchest and quantumtank, the superconductorwire, the aesu, and possibly the idsu out and leave the rest and not be especially annoyed leaving everything else out. even considering the ability to disable machines and go easy/hard config, some somewhat useful things have just been cashiered, like the first fusionreactor. the latter plays nicer for power distribution using liquid tesseracts vs just idsu methods but the overall performance to results arc is worse. what choice does the end user have if they wish to obtain versions with fixes to various bugs? update, which start a chain of the same, and world destroying/restartingly large morphology of the modified environment.
end of the day it becomes time to learn to write private mods to fill the gaps.
