Otherwise I'd be very careful, and especially if it's actually a language with multiple implementations.
Usually languages are extended. C++11 and C++14 are different languages, although the first is a subset of the second. That does not always hold. For example, Python2 and Python3 are different languages.
In line with the article: If you only provide a subset, give it a different name. Prepend a "mini" or "micro" or whatever. For example, "MiniPython" would be expected to provide a subset of Python.
This is why the authority for the language has version numbers. If it's just your compiler, it's a bit impertinent if not outright illegal to call it C 2.4.
And depending on the amount of changes, I don't think this is necessarily a good idea. Perl 6 comes to mind.
I think this is a bad example, because they want to abandon Python2 and move everyone to Python3, yet, almost 10 years later, many people are still using Python2. So I would say that the Python way is NOT how one should keep a language lean.
There is no perfect answer. Progressing, lean, and compatible: pick at most two.
But was Pascal ever more more minimal than C11? Maybe by some metrics, but the difference cannot be big.
Now there is plenty of stupidity in modern C standards, but that is mostly about letting compilers play hell with undefined behaviour in the name of over-aggressive optimisation. It doesn't fit in with the language-bloat thesis of the article.
I don't want to dismiss that: the "stupidity" I mentioned above is largely about making wrong decisions about those corner cases. Indeed, I suspect if the right decisions had been made, the standard could have been shorter. Though perhaps only by a factor two.
1. for as long as there is a champion to remind its practitioners, e.g. Wirthian languages at first
2. if they don't need to because they're extensible, e.g. Forth, Scheme, Smalltalk
Maybe these aren't the only requirements. Apache Groovy introduced annotations in version 1.7 so programmers could introduce their own syntactic extensions, and its backers often declared "no new syntax". Unfortunately, Groovy's project manager changed the @Trait annotation to a `trait` keyword in version 2.