Whereas I think the definition of value has only to do with bits.
That's because I prefer the "bag of bits" model to the "object" model.

My preferred model is:
1) An object is a region of storage and a type for interpreting its contents (which may include an alignment requirement).
2) A type has a contiguous object representation and a subset, possibly non-contiguous, value representation.
3) The value of a typed object is the sequence of bits in its value representation.
4) Two typed objects have the same value if their value representation is the same.
5) Having the same value does not imply anything about what comparison operators must report.  Two typed objects with different value representations may be == (e.g., +0.0 and -0.0) and a typed object may be not == to itself (e.g., NaN).
6) The same region of storage may be interpreted using any number of types.  (Therefore there is no "strict aliasing" prohibition.  Union type punning is fine too.)
7) Certain operations on objects (generally related to virtual dispatch) rely on implementation-defined parts of the value representation being properly set up by constructors and destructors.  Setting those parts up independently, in an implementation-defined way (say by using memcpy on the region of storage) results in objects that behave in the same way on those operations.
8) Types may have invariants that constrain values against addresses with respect to the region of storage, so that of two typed objects with the same value, one may meet its constraints while the other does not.
9) Uninitialized storage has arbitrary but consistent contents, so that it may be read and the same value will be read each time if read more than once.

(I don't care what words are used, so if you don't like "same" or "value", that's fine.  Other words will do.)