Well, you invited me, lol, so I am going to take a minute to do some recapping and hypothecating that is likely old hat for everyone, but I think necessary nonetheless....
First off, follow along a bit as I talk about a rather arbitrary continuum of kludge, patch, and redesign of a core filter.
As far as a kludge, bottom line is whether the kludge is the most economical resolution for a rare case to get by. Most are more than happy to decouple dragmath and add mathjax to head in additionalhtml - so the truth is, there may be only two reason to even address the underpinnings of the concern: a) for those who really need the the incremental utility provided by TexLive over Mathjax, and b) because beating a dead horse is always a good idea (and while I am being a bit tongue in cheek, as my discussion below suggests, not by that much....) Of course, what makes the interest in tweaking anything less inviting is the fact that TexLive is intended to be installed by the end user - that is to say that any user on a shared host need not rely on shared binaries..... and of course, any user on a shared system must, be definition, be able to make use of the MathJax CDN, though it is also easy enough to do a local install of MathJax on one's own server share. So, even at the beginning of our analysis it becomes dubious as to whether tweaking Moodle code is worthwhile.
But now we move to the patch, and arguendo, the basis for the patch is that there is a proven issue that impacts a clear portion of the population for whom a quick code change will resolve their problems. [yes, I admitted my distinctions as to kludge, patch and redesign are somewhat arbitrary and inaccurate, but I am not doing this as a basis to build the trade towers, but as a tool for posing the questions I am musing, and I think they serve for such purposes] But in the case of a patch we are typically agreeing that there is indeed a code problem, and, as well, that a patch is a better way to address the problem, than recommending other solutions (a local install of TexLive, for example.) I have yet to be convinced that there is a security hole, especially in light of the most recent suggestion that the problem may only appear when there is a font issue. This situation begs the question first noted above, and that is whether the claimed hang is in Moodle php or is in fact an issue in the underlying technology (the Tex or other binaries – I know that there have been some bugs in Tex resulting from missing items though I am not aware of any current bugs, but that makes no difference as who knows what version of Tex any user may be employing?) And is that the real problem here, i.e. relying on a distro of binaries for which you are not testing provenance nor completeness of distribution? Is it better to fiddle the Moodle php code, or simply try to intelligently address the nature of the distro that is being installed, which is in fact most intelligently done by having the user do their own TexLive install, which leads us to redesign questions.
A patch always poses the question of whether a redesign is necessary or appropriate, and that is indeed th question when we are talking about a filter that needs major reworking (I was going to do some of that but abandoned the work for a number of reason we don't need to rehash here.) The Moodle TeX filter expects certain performance from three binaries, two only of which are to be found in a Tex distribution, nor are all Tex distributions created equally. If the filter borks it falls back to mimetex, which was perhaps the best option at the time but even John argues that it is no longer. Among other things this means that Moodle will in a sense aggregate the vulnerabilities of its component parts. In this case the question that one arguably must ask first is whether the SA is concerned over a Tex security vulnerability, a Moodle vulnerability in calling the tex binary, or a Moodle configuration option, and whether arguably all of the above cold be resolved with a modern filter.
Sorry if some old hands get their noses out of joint, but the Tex filter is long past its prime - simply requiring that anyone who wants to use Tex has to have convert installed is about as ridiculous as all get out considering that convert has not been necessary for almost a decade, lol. What is the deal? Perhaps its that no one wants to fight with core devs who have stated that Math is not a core concern of Moodle, lol. Whatever the reason, the filter has seen better days and arguably its sole purpose is to provide options for those, as I argued above, who insist on a full installation of Tex because, for example, they want access to polynom But anyone actually needing this install is going to certainly be able to do a local install of TexLive, and an effective redesign of a Tex filter would allow Moodle to implement meaningful fallback for the 21st Century (and avoid ancient artifacts, like requiring convert) while avoiding the third party disputes between webhosts and Moodle users (which, unlike the current case, often involve folk who are WAYYYYY out of their depth.)
That all being said, what do I suggest one take away from this ramble? DO what you wish with respect to the Tex filter as almost anyone asking about Tex is being told to abandon that ship anyway! For those who do need a full install should tweaks be made to address such a situation as described above? I think not, as if the problem is with Tex, then it is a Tex problem which they need to fix, and beyond that there are ample solutions that minimize the sources of error. Indeed, I would rather see an install script in Moodle that actually did a TexLive install for the user and then configured the filter based on that install, than the current situation. This response is perhaps even underlined by the tentative results regarding fonts. Is it Moodle's responsibility to be the guarantors of the webhosts Tex distro? I think that is someplace we do not need to tread.
But, should it be demonstrable that this error could be forced, i.e. that there is truly an exploit possible if a full proper install is in place, that is another issue altogether. But so far, what we are talking about is a third party system continuing to try and source a resource that it can't find and I don't know that we have determined that there is no time out. As noted, not only can't we guarantee the distribution and its installation, we really can't guarantee the configuration. As a result I think we should not be mucking about with core unless we are going to fix things, and we are not going to fix things by tweaking this parameter. SHould it be determined that a specific configuration can cause an issue, we should flag that issue in the docs and perhaps provide a default preamble that explains the issue.
For many, it is almost an Herculean task to get Tex running on a shared host. adding hidden gotchas like would be the worst - but, suggesting a flag to the binary is arguably acceptable as long as it remains only that.............
I am afraid that I have been overly discursive and not helpful in the manner you had hoped, and for that you have my apologies, but I do hope I have been of some assistance.