GHC Haskell with all extensions... euh, I don't know. Many extensions are either syntactic sugar or straightforward changes to the base language, sometimes even making it simpler. But I'm not confident about all of them, and I'm not sure how the semantics of some low-level libraries (ie for concurrency) work out.
I've written code in essentially just the standard subset and it's a pleasant language—there aren't any extensions that you absolutely must use in real projects. That said, people use lots of them anyhow because most make the language nicer without adding too much complexity.
Since the extensions aren't organized in a unified way and have to be split up (since they can generally be enabled or disabled independently), it's hard to figure out how complex they make the semantics of the language as a whole.
Isn't it also true that undefined behavior can stem from varying hardware/platform considerations? In particular, leaving some things judiciously undefined allows flexibility in implementations and thus can give good performance across a variety of platforms. Sure, one could force some precise semantics, but that might result in unnecessary "emulation" code on some platforms.
So at a programming language level, by having such emulation/fixed behavior, the semantics are simpler. But at a low level, the semantics are more complicated as the machine instructions may differ significantly, thus losing transparency. This is a concern in quite a few resource constrained applications.
For a simple example, see http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and the section on oversized shift amounts.