Plural rules with "1=" in "Wikimedia:Convenient-discussions-thread-*" messages
In fact, there shouldn't be a problem with French in any case, if I read you correctly. Because the places where I used 1= don't have numbers in the output. That's the whole point. For example: {{plural:$1|There is a new message|There are new messages}}. 0 shouldn't matter here.
Another problem comes from the fact that when using "numbered parameters" (actually a plural selector), the follownig "unnumbered parameters" are also given implicit keys, so there is a collision; this should normally not affect effective "parser functions" of Mediawiki, but this causes a confusion depending on the way these messages are parsed. The MediaWiki parser does not process parser function calls exactly the same way as template transclusions (where these collisions are ocuring because all template parameters must be given a unique "name" used as keys in the same table of parameters, whereas parser function calls treat all parameters in a table keyed only by integers and whose entries are (paramname=value) pairs, so that all parameters can be processed in the expected order and can even specify the same "paramname" multiple times (we can't assume that in templates).
So parserfunctions calls like {{Plural:...}} work differently than transclusions like{{Plural|...}} (and this complicates things in MediaWiki because transclusions may give a page name for the template which may also have a namespace prefix: the distinction is not made by the syntax, but by first parsing MediaWiki like with parserfunction calls, then remap the integer-indexed array of (key=values) pairs into a table keyed by parameters (voiding their order) only when this syntax des not map to a parser function call but to a template transclusion.
Anyway this is a case where we are in borderline of very tricky cases, that translators should not have to care. Specifying plurals rules (or gender, and other 'tagged grammar") in translations is something that is still not cleanly solved in translatewiki.net and translators have difficulties to figure out if this works and how: even for MediaWiki alone there are several syntaxes used (depending on whever the MediaWiki parser will process the message or not, or if it will be processed by some other i18n library or directly in PHP; as well this complicates imports/exports and compatiblity with other formats (notably .po for Gettext, which is the least permissive).
Ideally we should support plural cases using CLDR rules only (using symbolic selectors like "one", "two", "few", "many"), and specific cases with numeric selectors should never be used in translation units. But we have to live with the legacy implementations and with the "strange" Mediawiki parsing rules. But even the CLDR rules have also evolved over time (see the specifications of LDML, now hosted by the Unicode Consortium and no longer depending on the legacy IBM version of ICU...). Finally there's an interesting evolution used in FreeCol, which allows a more generic and unified solution for supporting arbitrary number of linguistic features (not just plural, gender or grammatical case, it can also support lexical types and semantic classifiers) using its own {{Tag:feature|...}} syntax, where the feature can be also defined by translatable units (so a feature can also be made for a specific language!) or use its own rules for parsing, aliasing and resolving fallbacks!
And if you still think that French is complicate for you, just consider the case of Celtic languages (which have many more plural types) and Slavic languages (using complex rules, not based of the value but just on the two least significant digits of the integer part of the value, and that also influce the derivation of other words, notably their grammatical case!)
Ideally the Freecol solution could also solve the problem existing as well in languages using complex mutations and elisions (French, Italian, Celtic languages...), or complex agglutination and deagglutination (including verbal affixes in German which are also reordered ni the sentence), or rules depending on semantics of lexemes (which adopt variable forms, or have complex cases like "amour" vs. "amours" in French which changes from masculine to feminine when going from singular to plural, or the way English changes some "or" into a "nor" in some negated phrases...). Those linguistic subtle things are discussed since long in CLDR (but still not solved as there was no working implementation, only some specific code used in specific applications, so resolving that issue was postponed), but with the newcoming Wikimedia projects for "Wikifunction" and "Abstract Wikipedia", we'll definitely have to work on that, and we'll need to create a more formal specification that will allow translation validators to really work (while preserving the compatiblity with existing i18n libraries and tools)!