To (monkey)patch or not to (monkey)patch, that is the question

[George Sakkis]

I was talking to a colleague about one rather unexpected/undesired
(though not buggy) behavior of some package we use. Although there is
an easy fix (or at least workaround) on our end without any apparent
side effect, he strongly suggested extending the relevant code by hard
patching it and posting the patch upstream, hopefully to be accepted
at some point in the future. In fact we maintain patches against
specific versions of several packages that are applied automatically
on each new build. The main argument is that this is the right thing
to do, as opposed to an "ugly" workaround or a fragile monkey patch.
On the other hand, I favor practicality over purity and my general
rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
least for anything less than a (critical) bug fix.

So I'm wondering if there is a consensus on when it's better to (hard)
patch, monkey patch or just try to work around a third party package
that doesn't do exactly what one would like. Does it have mainly to do
with the reason for the patch (e.g. fixing a bug, modifying behavior,
adding missing feature), the given package (size, complexity,
maturity, developer responsiveness), something else or there are no
general rules and one should decide on a case-by-case basis ?

George