letrec

Isn't
(letrec ([is-even? (lambda (n)
                    (or (zero? n)
                        (is-odd? (sub1 n))))]
         [is-odd? (lambda (n)
                   (and (not (zero? n))
                        (is-even? (sub1 n))))])
        (is-odd? 11))

equivalent to...

(let
    ([is-even? nil]
     [is-odd? nil])
    (set! is-even? (lambda (n)
                    (or (zero? n)
                        (is-odd? (sub1 n)))))
    (set! is-odd? (lambda (n)
                   (and (not (zero? n))
                        (is-even? (sub1 n)))))
    (is-odd? 11))

>>44

But specifying things like that prevent implementations from providing the main functionality in the fastest way possible. I gather the problem with the memcpy thing is that some implementations would copy from back to front, while others would copy from front to back, causing strange effects if the regions overlapped? So if you specified the order of the copy, then overlapping in one direction would always work, and overlapping in the other would always fail. But what if you had some processor A that could implement back to front copying really fast (maybe it had a single instruction for it or something), and it couldn't do it the other way as quickly. The order of the copying is irrelevant for correct usages of memcpy, and insisting that the slower order always be taken will piss off people using processor A who use memcpy the correct way. The solution isn't to make memcpy do memmove, it's to educate people to use memmove when needed instead of depending on undefined behavior of memcpy, and to use memcpy when memcpy's behavior is defined.