Problem definition: I feel most of the problems on SO were not as rushed in as they are here. The beta status tends to push us in a "we need questions asked or else" mood that's detrimental to quality.
Problem size: There are some long and complex problems out there (check the "unanswered" page), but they're definitely not low-hanging fruits. Less traffic, less votes, less visibility. And beware the other edge of the sword: some of the most complex ones I'd never answer myself, they've been dismissed as too boring long ago. Partial personal list: Self-compiling compiler (TCC's already out there), Write a compressing util for gzip files., Implement PCRE in your language. FWIW, I also tend to dismiss problems where I feel there's no right way to rank out the answers, and would end up in a language popularity contest. (and this already happens quite a bit in actual well-phrased problems)
Lax requirements: I'm guilty of this myself, as a reaction to the over-strict problems where the requirements subconsciously favor a single perspective in programming languages. This could be addressed with a few templates for "classical" problem categories, where we'd agree what the normal way of processing I/O is, what tolerances
are usually allowed to specific languages. As templates, they'd be overridable per problem.
As far as I'm concerned, a major part of the fun of golfing is bending the requirements as far as possible in the small code size direction. I love seing a solution output unexpected mixed-case or random spacing as a side effect of shorter code. I smile at solutions that work 90% of the time because they run their luck on the number of set bits in their PID. Most of this, and the fun that goes with it, tends to be rubbed away with too strict requirements.
I'm not sure I see what you mean about presupposed languages.