Touching the filesystem implicitly can have all sorts of unintentional side effects (especially in read-only environments), so we strongly prefer not to do that.

The most general solution here would be to turn the warnings registry into an LRU cache - short-lived applications wouldn't see any changes, while long-lived applications with changing warning messages would hit the upper bound and then stay there.

I also like Victor's change to have the "ignore" option skip touching the registry. If we decide we still want to optimise out the linear filter scan for those cases, then I'd suggest lazily building a dispatch table with separate per-category warnings filter lists (updating the dispatch table on the next emitted warning after the filter list changes), and then only falling back to scanning the full filter list for warning categories that aren't an exact match for anything in the dispatch table.