> The real issue was ugly code that was in the product when it was acquired
IME, this was the norm for Perl projects, not the exception. And you explain the reason for that:
> We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
Yes, it's true that a disciplined, mature, skilled team can write good code in any mainstream language. But in practice, there are far more teams that lack enough of those qualities, that using what I'm calling a bad language will contribute to them producing hard to maintain, buggy code.
If you're defining a subset of a language as being good, you're proving the point about the overall language not being good. This is why Perl failed - because its real-world use more often than not produced poor outcomes.
> Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context
That doesn't sound like the right approach - it sounds like you really want the opposite of a singleton. In most languages, you'd just pass a different logger instance, either as an argument or in an object field.