These two types are actually incompatible with each other according to the C standard, and a function that is declared more than once in different translation units with different declarations is considered undefined behavior. Thus, any correctly conforming C library will cause any code that includes string.h to be undefined.

Interesting find, but... how meaningful is it really? As you say, "any correctly conforming C library will cause any code that includes string.h to be undefined". But if the C library included with OS X is coherent with the .h file (and thus not strictly conforming to the standard), then no Undefined Behavior should appear.

The consequence is that if I write code on OSX that assumes that the C library is not restrict-qualifying these types, that code may not port to other platforms, and may lead to extremely subtle bugs that are not visible at the source level because the arise from the way in which the C compiler is optimizing aliasing restrictions.