Your package contains a dangling symlink:

,----
| $ file /usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so
| /usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so: broken symbolic link to libSDL2_net-2.0.so.0.0.1
`----

This symlink is created via dh_link in debian/rules with a comment that
it exists to fix a dev-pkg-without-shlib-symlink lintian warning.  It
seems that this warning does no longer trigger, though.

Control: severity -1 normal
[note lack of RC severity]

I don't think this is a RC bug unless other packages are relying on the
dangling symlink to point to something useful, which it appears they are
not (see <https://codesearch.debian.net/search?q=SDL2_net-2.0&literal=1>).
The canonical name of this library for linking purposes is SDL2_net,
as in `cc -otest test.o -lSDL2_net`, which results in linking to either
libSDL2_net.so or libSDL2_net.a (and there is no libSDL2_net-2.0.a).

The libSDL2_net-2.0.so symlink would only be required if someone is
linking dependent programs or libraries with "-lSDL2_net-2.0", and it
seems nothing in Debian does that.

Unless there is a reason why this needs to be considered release-critical
that isn't obvious to me?

When elevating a bug report to release-critical, please mention why you
believe it's a release-critical problem in a mail to the bug, otherwise
the maintainer has no context for it (and might not even be aware that
its severity has been raised).

I agree that the dangling symlink is a bug, and libSDL2_net-2.0.so should
either not exist, or point to a file that exists (the easiest would be
libSDL2_net-2.0.so.0, matching what happens in the rest of the libsdl2
family).

The libsdl3 prerelease in experimental has removed this weird
historical versioning thing, and just ships libSDL3.so, libSDL3.so.0
and libSDL3.so.0.0.0, as is conventional; the extra names with -2.0 in them
are a historical quirk of the upstream build system for the libsdl2 family,
which used `libtool -release`, apparently due to a misunderstanding.

    smcv

Thanks for this analysis showing this is a cruft symlink. Usually a
broken .so symlink means a missing dependency, missing packaged library
or renamed target (without updating the link), which are RC, as one
cannot link to the library (via the intended name).

Andreas