There are a few cases where the content model wants to tweak parser options. These are both handled in includes/page/WikiPage.php right now, but as a huge & ugly hack:
* LanguageConverter "conversion tables" should have content conversion disabled on them, so that they are viewable. There's a comment in WikiPage that was "ConversionTable should become a separate content model, so we don't need special cases like this one" but (as the title of this bug lays out) that wouldn't by itself help, because there's no current way for a `ContentModel` to tweak the `ParserOptions` used either.
* JavaScript and CSS want to be "parsed as wikitext" so that categories and PST expansions work, among other features (magic words, links will add the page to "what links here", etc) but do *not* want to actually /render/ as wikitext. Since they are not actually wikitext, they don't want a ToC generated either (T307691) just because they might happen to have `==` or `<h2>` embedded somewhere. ToC is suppressed by setting `ParserOptions::setSuppressTOC()` but this *ought* to happen in the ContentModel somewhere/somehow, not by a WikiPage hack.
As @daniel says, "the actual solution would be to allow Contenthandler to use different (or cloned and adjusted) parser options for the 'fake parse'" -- although the Conversion Table can is slightly different, since it's not really a "fake parse" in that case.