"We could consider memcpy to implicitly begin the lifetime of a new bool..."

memcpy does not implicitly create objects. (corrected by Jan below) You're scribbling over the object representation of "b", which ends the lifetime of "b", and any access to "b" is thus undefined behavior.

Unless you show a real example where the situation can happen outside of erroneous values, this change is rejected. When CWG reviewed the wording not too long ago, we could not come up with an example. We believe we have sufficient wording elsewhere so that we cannot otherwise be in a valid situation where we try to read a bool from random garbage bytes.

Also, this changes the normative content of the standard (thus can't be an editorial change); I'm not seeing that [defns.access] by itself would somehow cause undefined behavior.

memcpy does not implicitly create objects.

[cstring.syn] p3 literally says:

Both functions [memcpy and memmove] implicitly create objects [...]

Unless you show a real example where the situation can happen outside of erroneous values

I have shown that example. The only reason why that code is UB is because 0x02 may not be a valid representation that corresponds to true or false. If it was, then the example would be well-defined. This is exactly the same reason why erroneous valued value representations may or may not correspond to a value for the type.

If we have another situation where a bad bit pattern can end up in a value representation and we can read from it before hitting undefined behavior earlier, the right fix is to strike the "erroneous value" part of the normative phrasing. That's not editorial, of course.

That's not editorial, of course.

I see it as editorial because it is already undefined behavior given that there is no value that can be read by lvalue-to-rvalue conversion in the first place. If the second sentence is redundant and any such case is already UB, it could be deleted (or turned into a note) and it wouldn't change the semantics of the standard or impact any implementation.

I guess this is getting too controversial for CWG not to see it though, and I should open a CWG issue about this.

Even memcpy can implicitly create objects, per [intro.object] p11 it may create zero object and leave existing objects living. And the UB doesn't seem to depend on whether a bool object is (re-)created or the existing bool object merely gets its value representation replaced. It does only depend on a (probably) wrong object/value representation, IIUC.

FYI P2624 seemingly wants to eliminate such UB.

CWG2899

The core issue has been approved.