<< IMO, the real question is why dead-end hacks are being included in staging in the first place.
IMO: If not in staging, then there should be an alternative place for such hacks or patches, ideally that the AppDb can point to. People go to the AppdDb to see if an app they want or need can run ... They'll be more impressed and potentially get involved in Wine more in some way if it helps them. You can make all sorts of usual disclaimers about not part of pure process and may break at anytime etc. Accepting such hacks (somewhere) can potentially introduce a wider developer (of varying Wine based aptitude) base to draw from. The hack could provide a basis for either progressing/converting it to non dead end approach by either mentoring the original author(s) Or providing stimulus for another to take on and submit a more acceptable patch. The hack may also allow sight of further bugs down the line in the app(s) it was intended for, which sometimes helps with tackling the original issue(s) and the solution approach.
<< IMO if the patch solves the bug for a user, and the patch is in staging, it should be marked STAGED. The whole point of staging is that the patches may not be up to par, but are good enough for some purpose. If Office works and it didn't before, I'd say that standard is met.
+1 Ken.