I used this term "temporary expression" in my DR with the meaning of what now is simply a prvalue expression and compared it with "bitfield lvalue", where "bitfield" is also a property of the (lvalue) expression and influences the compilation (for example it can result in illformed reference binding attempts).

In [class.base.init] we actually must not use "temporary object", but need to say "prvalue expression" or "xvalue result of the temporary materialization conversion" or something to that effect, because in general the properties of objects referred-to by glvalues are unknown at compile time (including whether they are temporary objects or not).

I think ideally [class.base.init]/8 and /11 should make a member initialization ill-formed when and only when the initialization is a reference binding described in [class.temporary]/6 ("when a reference is bound to a temporary object").

That is, it should not prohibit struct { std::ostream& r = std::ref(std::cout); } x; even though std::ref(std::cout) is a prvalue, I think, so perhaps "prvalue expression" is inaccurate.

Using "xvalue result of the temporary materialization conversion" seems to work, but is less helpful, since it fails to catch some of the cases listed in [class.temporary]/6.

I missed the nuances of [class.temporary]. What I thought the term "temporary expression" means is decoded in those bullets.

However the "exceptions" listed after those bullets are defective (as far as I can tell), since they stop constraining the expression to have such a form. The rule "A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing the call." can apply to the function call in this snippet:

void f(const int&);
const int &a = 10;

// temporary object is bound to a reference parameter here!
f(a); 

My inquiry is that when we fix [class.base.init], we should be more precise. Perhaps [class.base.init] and the exceptions in [class.temporary]/6 should be fixed together as to avoid this kind of ambiguity. Requiring the reference binding to be one that is described in those bullets seem to work fine, as in

<ins>For such a reference binding,</ins> the exceptions to this <del>lifetime </del>rule are:

Editorial meeting consensus: drop "temporary expression" from expr.comma. For the reference binding cases, we say "bound to a temporary object whose lifetime would be extended (class.temporary], program is ill-formed".

[expr.comma] has already been fixed.

cplusplus/CWG#200 is a duplicate, IIUC.
FWIW, I don't understand what's wrong with just changing the word "expression" to "object". References bind to [temporary-or-otherwise] objects, not [temporary-or-otherwise] expressions. I don't see why that wouldn't be a complete fix.