There's really not anything wrong with doing that as long as everyone can stomach the costs, benefits and risks.
...the fix seems simple enough ... to patch the code myself
When you have a job to do, perfect (having a third-party library that's exactly what you want) is the enemy of good enough (patching it yourself), and sometimes you have to do things like that. I've done a number of projects where we've bought source licenses for commercial libraries so we could fix problems before the vendor got to it.
...detractors want to argue the case that this is nearly always
a bad idea in that it is risky and introducing a troublesome complexity.
It's a bad idea if you don't have the chops to handle dissecting someone else's code, identifying a problem and writing a fix. That's true whether the code is in-house or a third party; the only difference is whether it was thrown over a cubicle or building wall before it landed in your lap.
If your detractors are simply brushing the idea aside without weighing the costs of not doing this patch, they're not doing their homework. If you have a lot of in-house code that's affected by the bug your patch would fix, you'll have to go through and change it to work around it and re-test everything to be sure it works correctly. Then, should you ever upgrade the package to a bug-fixed version, you may have to find and remove your workarounds and re-test again. There are risks to doing that as well, like missing a case you changed or insufficient testing. Personally, if I have the opportunity to fix a bug at its source, I'd much rather do it there than chase around the rest of the code with a flyswatter and hope I get everything.
...code change was done by us ... it must be part of our code base
...we must introduce it as a new project and incorporate its
automated build into our build process.
If you're doing a patch, the patch is part of your own code, which means you have to make it part of your process. This isn't any different than adding something that's 100% your code to your system. Treat the third-party distribution as sacrosanct and put it into a module just like it were source code. Any patches you write are stored with it in separate files and applied as part of the build process. That way you always go from clean source to patched source to built product and can show exactly what's going on. (Some folks unpack, hand-patch, re-pack and store that in version control. That's bad.)
...we would be pulling their code from their source control repository
into ours, and we lose the history behind any code changes...
If you're treating the third-party library as a third-party dependency, you don't have that history to begin with and you're not losing anything. If you have continuing access to the third party's repository, you can consult that should you need to. The third-party releases should be treated like amorphous blobs that you check into your own system unaltered. If you need to look at changes between the release you're using and later releases, you can do that and, should you want to, come up with patches to the old version that incorporate changes you want.
Also it just seems like something that is far too complicated for
such a small code change that needs to be made.
If your build process is sufficiently sophisticated, adding this shouldn't be any more difficult than adding your own code. There's a small amount of labor in getting it to the point where the unpack/patch/build process is automagic, but once it's done, it's done forever. There may be one bug now, but there could be twenty in the future. If there are, you'll be much happier that you laid the groundwork to support all of that now, because it will make dealing with the next 19 much less work.
