I seem to recall that "systems programming" was initially penned meant what we now call "application development" [1]. I realize that these days, the two tasks are considered very different, but as far as I understand, that's "just" because we now have access to high-level APIs, the likes of which didn't exist when the name was invented.

In my book, it's "system programming" when you are writing an application and you need to reach to lower-levels than what your language/stdlib/framework typically allows. So the authors of the DeepSeek training mechanism were doing system programming when optimizing communication between cores, but also anybody who sets out to optimize a Python-based app by writing a Rust module, or a Rust developer when they're calling directly into libc, or a C developer when they're writing assembly or performing syscalls, etc. Of course, by this definition, there's no such thing as a "systems programming language", but there are languages that can serve for system programming of other languages.

[1] Which seems to be confirmed by the article, in fact.

I don't think this is right. Systems programming is a broader term that can include embedded systems, compilers, virtual machines, game engines, etc. At least that's my perception based on how it's commonly used.