Lock tag types are defined twice, once incorrectly

[Quuxplusone]

https://eel.is/c++draft/thread#lock.general-2 says:

Some lock constructors take tag types which describe what should be done with the lockable object during the lock's construction.

namespace std {
  struct defer_lock_t  { };     // do not acquire ownership of the mutex
  struct try_to_lock_t { };     // try to acquire ownership of the mutex
                                // without blocking
  struct adopt_lock_t  { };     // assume the calling thread has already
                                // obtained mutex ownership and manage it

  inline constexpr defer_lock_t   defer_lock { };
  inline constexpr try_to_lock_t  try_to_lock { };
  inline constexpr adopt_lock_t   adopt_lock { };
}

But this isn't the actual correct definition of defer_lock_t et al.; those are normatively defined further down in
https://eel.is/c++draft/thread#mutex.syn as having explicit default constructors.

struct defer_lock_t { explicit defer_lock_t() = default; };
struct try_to_lock_t { explicit try_to_lock_t() = default; };
struct adopt_lock_t { explicit adopt_lock_t() = default; };

inline constexpr defer_lock_t  defer_lock { };
inline constexpr try_to_lock_t try_to_lock { };
inline constexpr adopt_lock_t  adopt_lock { };

IMHO we should figure out a way to strike the first (non-normative?) definitions entirely. At worst, the first definitions should be updated to match the correct normative definitions, so that nobody gets confused.

[jensmaurer]

Please submit an LWG issue; the redundancy should be removed, but there's a lot of LWG discretion involved on what exactly the result should look like.

[frederick-vs-ja]

I think the decision on explicit default constructors is already made in LWG2510.