SonarLint reports the latter to be better:

std::scoped_lock basically provides the same feature as std::lock_guard,
but is more generic: It can lock several mutexes at the same time, with a
deadlock prevention mechanism (see {rule:cpp:S5524}). The equivalent code
to perform simultaneous locking with std::lock_guard is significantly more
complex. Therefore, it is simpler to use std::scoped_lock all the time,
even when locking only one mutex (there will be no performance impact).
Signed-off-by: Rosen Penev <rosenp@gmail.com>

When the client wants to seek, but the decoder has already finished
decoding the current song, the player restarts the decoder with an
initial seek at the new position.  When this initial seek fails, MPD
pretends nothing has happened and plays this song from the start.

With this new flag, a restarted decoder marks the initial seek as
"essential" and fails the decoder if that seek fails.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/895

The former is deprecated by C++14. The standard says they are the same:

The header defines all types and macros the same as the C standard library
header<stdint.h>.
Signed-off-by: Rosen Penev <rosenp@gmail.com>

The former was deprecated with C++14.

According to the C++11 and C++17 standards, both files are identical.
Signed-off-by: Rosen Penev <rosenp@gmail.com>

This optimization is useless because sane pthread_cond_signal()
implementations check the number of waiters and do not invoke a system
call if there are none.

The check IsSeekableCurrentSong() was added by commit
44b20024 in version 0.20.19, but it
caused a regression: by doing the branch only if the current song is
seekable, the player would restart the current song if it was not
seekable, and later the initial seek would fail; but we already know
it's not seekable, and so we should fail early.

This requires re-adding the reference to struct DecoderControl, which
was removed recently by commit
9f14e7a9

This tiny amount of overhead allows omitting the MusicBuffer in
Clear().

This adds a bit of overhead, but also adds flexibility to the API,
because arbitrary triggers may be invoked from that virtual method
implementation, not just Cond::signal().

The motivation for this is to make the handlers more dynamic, for the
upcoming buffering class utilizing ProxyInputStream.

When switching to another song manually, the player checks if the
decoder is already decoding that song; if so, it will attempt to reuse
it by seeking it to the new position.  That however fails if the
decoder is not seekable (e.g. a radio stream) which leaves the user
unable to switch to that song with the bogus error message "Not
seekable".

This eliminates some overhead, because the compiler doesn't need to
consider these functions throwing.