To start with the conclusion: everything appears to work as intended, so this should probably not be considered a bug as such, but some logging and telemetry output could be improved to make things clearer.
If you use -bind to manually specify which (public) IPs to listen to, Bitcoin Core will also no longer create the (local) default socket for incoming Tor connections at 127.0.01:8334 unless you specify it manually in your list - this is probably working as intended. When automatically creating a Tor hidden service, it will instead be routed to the public IPv4 port, and incoming Tor connections still work just fine.
However, without the dedicated Tor socket, Bitcoin Core is unable to distinguish between regular IPv4 connections and Tor connections, so all of the latter will be counted as the former.
The specific case that had me scratching my head for a bit: -netinfo reported zero incoming Tor connections
0 ipv4 ipv6 onion total block
1in 291 28 0 319
2out 5 3 2 10 2
3total 296 31 2 329
while the true number of incoming Tor connections was 29.
0ss -tupan | grep tor | grep 8333 | wc -l
129
As expected, removing the -bind statements from the config and restarting fixed it.
0 ipv4 ipv6 onion total block
1in 25 4 5 34
2out 4 1 5 10 2
3total 29 5 10 44
While the documentation for -bind hints towards why this is the case, Bitcoin Core gives no indication in the logs or the -netinfo output that the configuration is suboptimal, and I feel like maybe it should do that just to save people (like me) from getting confused.
Maybe during startup, if no Tor socket is created and a Tor hidden service is created, it should add something like “Warning: -bind was specified but lacks a dedicated Tor socket; incoming Tor connections will be counted as regular connections”, and when using -netinfo it should show a “?” or “-” instead of “0”.