The problem is the actually often the opposite, in the real world many treat strncpy as if it behaves like strlcpy. Note that strlcpy is equivalent to:

    snprintf(buf, sizeof(buf), "%s", string);

strlcpy is on track for future standardization in POSIX, for Issue 8, but even as a de facto standard, it exists in libc on *BSD, macOS, Android, Solaris, QNX, and even Linux using musl.

https://www.austingroupbugs.net/view.php?id=986#c5050

But you're correct in that it is not a replacement for strncpy because no code should be using strncpy.