I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. If you succeed at that, I further challenge you to: find me two concurring definitions of systems programming language that include enough detail to qualify and disqualify languages consistently.
By "enough detail" and "clear bounds" i mean: a group of people independently arriving at the same sets of classification based on your provided definitions.
>I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming.
There's no such thing - that was the whole point of my comment.
A systems language is not such because of conforming to a definition, it's a delibarate classification ("this language is, that one isn't" as opposed to "this langauge is because it conforms to this definition"). And that "is/isn't" isn't even up to the individual programmer, it's cultural.
There are characteristics that drive this classification, but it's not driven by a strict definition. It's more of "know it when I see it" kind of affair.
By "enough detail" and "clear bounds" i mean: a group of people independently arriving at the same sets of classification based on your provided definitions.