Lock tag types are defined twice, once incorrectly

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.

Compare the introductory tag-type definitions in [thread.lock] with the normative definitions in [thread.mutex.syn] using the linked draft sections. Determine whether the first definitions can be removed or should match the explicit constructors in the normative text; done means the draft no longer presents conflicting definitions.