I think it really depends on the use case, no? You can design a framework to be more or less restrictive, and the best tend to be less so, (which allows you to do stupid things but has good guidance on how to NOT to do that).
For instance, you could have an http framework that handles things like compression, buffering, timeouts etc, which are likely to work everywhere. But you could also design it such that each mime type comes with a separate class, like a HTMLTreeBuilder, or something like that, which would be horrible and way too constrained.
Elaborate type systems can, in some cases, seduce this kind of overengineering. If it really looks like something can be modeled as a type, chances are that the author cannot resist it.
For instance, you could have an http framework that handles things like compression, buffering, timeouts etc, which are likely to work everywhere. But you could also design it such that each mime type comes with a separate class, like a HTMLTreeBuilder, or something like that, which would be horrible and way too constrained.
Elaborate type systems can, in some cases, seduce this kind of overengineering. If it really looks like something can be modeled as a type, chances are that the author cannot resist it.