Is there a technical reason why the l- and r- values for opEquals must be const? If the restriction is purely for the intuitive notion that there's no heisenstructs, then I have an example I think might be worth consideration: lazy caching.
If comparison isn't always needed and requires a potentially expensive computation that isn't likely needed otherwise (for example, a wrapper for string that does case-insensitive comparisons, if it's used in a situation that does more assigning/slicing/etc than comparing), then it may make sense to wait until an opEquals is called, and then compute the information and cache it. But that requires mutating state and so can't be done in a struct opEquals. 'Course, if there is a technical reason for the restriction, then all this is moot.
