What is the rationale for not including strdup in the C Standard?

Question

Most C programmers are familiar with the strdup function. Many of them will take it for granted, yet it is not part of the C Standard (neither C89, C99 nor C11

Answer 1

The quoted link in the comments (http://open-std.org/JTC1/SC22/WG14/www/docs/n718.htm) gives an explanation about what is "wrong" about having strdup in the standard library:

The major issue was the desirability of adding a function to the standard library which allocates heap memory automatically for the user.

Basically, the C language and its standard library try their best not to make assumptions about how the user allocates and uses memory.
It gives a few facilities among which are the stack, and the heap.

While malloc/free are standardized for dynamic memory allocation, they are by no means the only way to do so, because dynamic memory management is a very complicated topic and the default allocation strategy might not be desirable for all kinds of applications.

There are for example a few independant libraries such as jemalloc which emphasizes low fragmentation and concurrency, or even full-fledged garbage collectors such as The Boehm-Demers-Weiser conservative garbage collector. These libraries offer malloc/free implementations that are meant to be used exclusively in replacement to the standard *alloc and free functions from <stdlib.h> without breaking compatibility with the rest of the C standard library.

So if strdup was made standard, it would effectively be disqualified from being used by code using third-party memory management functions (it must be noted that the aforementioned jemalloc library does provide an implementation of strdup to avoid this problem).

More generally speaking, while strdup certainly is a practical function, it suffers from a lack of clarity in its semantics. It is a function declared in the <string.h> header, but calling it requires to consequently free the returned buffer by calling the free function from the <stdlib.h> header. So, is it a string function or a memory function ?
Leaving it in the POSIX standard seems to be the most reasonable solution to avoid making the C standard library less clear.