The same concern definitely crossed my mind as a reader, but I think the coloring of the critique should be less #000000 and more #888888. A lot depends on the technical goals of the "P++" variant - and on the culture among the language maintainers.
* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."
By providing PHP-backwards compatibility HHVM, Facebook provided an off-ramp for themselves and other existing PHP users at a time when HHVM was much faster than the PHP interpreter.
But then PHP sped up, and once it became clear that people had stopped using that off-ramp, Facebook demolished it. The off-ramp was infeasible to maintain, and of no benefit to anyone.
* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."