The key problem with memset is not being *certain* that the overwrite occurred. In that sense, a read-back at the user's level is meant for two purposes:
1. Prove to security-minded skeptics that the sensitive data is being cleared. (See note 1 below)
2. Allow for side effects such as logging "if" the clear does not occur correctly.
For both A and B above, the issues are that memset cannot be relied upon, and that logging may be required on failure. The only way to confirm that the erasure has occurred is to check it, or to trust the compiler (if secure_clear guarantees read-back). See note 1 below. Basically, the problem boils down to this for me: Either we use memset + read-back (and audit on failure), or we use secure_clear (and possibly audit on failure). If I can't verify and audit on failure, then I'd probably never use the secure_clear.
*Note 1*: In my experience, security-minded certifiers may not understand or have a lot of faith in the compiler. This may not be an accurate view of the world, but it's a very difficult view to argue with. More importantly, often we would want to require multiple faults before a failure occurs (i.e. part of normal reliable system design). In this case, either read-back or multiple overwrites could ensure multiple faults must occur to cause a failure (to clear sensitive data). When a failure *does* occur, you probably want to create some kind of log so the event can be traced and corrected in the future. Hence, the ability to introspect the buffer of sensitive data afterwards is important.
*Note 2*: Regarding the multiple translation units comment, I think the biggest problem there is a lack of clarity. I'm not certain your average software developer may appreciate the subtleties of compilation and linking. Relying on that sort of behavior today would not be desirable, in the same way that relying on a memset w/ no read-back is undesirable. Put differently: I would prefer explicit behavior to implicit behavior.
Maybe the problem here at root is that for people with low trust or high security requirements, a secure_clear() just won't be "good" enough. Still, there's an argument that a secure_clear should be good enough for the average developer. Maybe that's enough.
Daniel