Re: The real culprit
Is the deliberately holed *nix security model
With respect, I understand your viewpoint but I don't think that the setuid mechanism is fundamentally broken. I think that it's a really elegant solution for the problem of privilege escalation.
All OSes need to have the ability to run protected or kernel-level code and means of making them available via userland in some way or other. Unix-like systems (the hint is in the name) have a unified approach where root can do anything and for the most part, barring obvious programming errors, this works. Neither does the setuid model preclude you from adding extra "boundary checks", as you put it, if you want to (*). If you want more fine-grained control (was it VMS that had "capabilities", for example?) then that can be implemented within the setuid program (or use regular file permissions; though I guess you don't like the user/group idea either).
By design, the *nix model is that if you are root you bypass all security checks.
This is the main thing I disagree with. You are forgetting that root does not exist in isolation. Yes, root can run anything, but setuid programs (and user/group permissions, as above) are the gatekeepers. So in fact, even though you say there's no "security boundary", that's not true: you don't get unfettered access to root, but can only do what the permissions and setuid programs allow. As I said above, these interfaces can be used to express any sort of security model you want.
This bug was particularly stupid since the golden rule of writing setuid programs is (probably, if there were a "golden rule") not to trust any user data, environment variables included. Oh, and for Gods' sake, make sure they're statically linked so that they can't be tricked with an LD_LIBRARY_PATH. So I blame the designers, programmers and review team, not the design of Unix. No-one with an understanding (and it's not difficult to understand) of how the Unix security model works should be making these mistakes. Nor would they be making the complaints that you're making, I feel.
(*) I may follow up on this in another post.