PHP core enables -{...}- syntax parsing only if $wgDisableLangConversion is false (which it is for all deployed WMF wikis in production) and the page language for the current page has a defined variant. (Even if all variants for the given page language are disabled via $wgDisabledVariants.)
This is somewhat unfortunate, since it makes parsing depend on the current status of various variant tables in the PHP core, which can change over time. For example T45547: MediaWiki needs a fictitious variant for English for easier variant development work is complicated by the fact that merely adding a variant for English would change the parsing of enwiki by turning on -{...}- parsing on all English pages, even if the pig latin variant is disabled. It also requires you to know the pagelanguage for the current page before tokenizing the wikitext.
The first proposed solution to this problem was to honor only $wgDisableLangConversion, and turn on -{...}- parsing regardless of pagelanguage. This is the cleanest solution, but it made @tstarling quite nervous. It greatly expands the number of pages LanguageConverter is enabled for, and it is generally felt that LanguageConverter is a vulnerable piece of code.
Failing that, we need to export the necessary information to allow Parsoid to determine if languageconverter should be enabled for a page. Specific proposals are discussed below.