Re: alternative to "trashed"

I think I would look at the whole issue of "semantics of destructors"
a little differently.

As in CLU or other languages that support data abstraction, a C++ class
can have some invariant that class operations can assume on entry and
must preserve on exit.  C++ even supports this well by providing
fairly strong guarantees that classes with constructors will have a
constructor called for each instance of the class; thus constructors
are distinguished member functions which don't get to assume the class
invariant but do have to establish it before exiting.

Symmetrically, destructors are distinguished member functions that get
to assume the class invariant on entry, but aren't required to
maintain them on exit.  Thus, if a class has a non-trivial invariant,
it is necessarily illegal to call a member function on an object after
its destructor is called; you can't establish the pre-condition that
the invariant holds!

I think the issue of storage being "trashed" is separable from the
semantics of destructors.  I would claim that the right way to think
of an expression like "delete p" where p is a pointer to an object of
a class T with a destructor is

  ::operator delete(p)

(unless T has an overloaded operator delete, of course.)  Note that
the syntax of the first line is quite legal; you can invoke a
destructor on an object without using delete.  So my point is that its
the specification of "::operator delete" that has to deal with
"trashed" or "last_use" or whatever.

I hope this point of view is helpful...