GIMP downloads page has had a torrent option for a very long time. Their torrent files list all the regular file server mirrors as web seeds. When I add such torrent, Tixati starts to download from those mirrors at full speed before it even learns about any of potential bittorrent peers.

It seems that GIMP project at least partially depends on torrents and mirrors to deal with peak usage at release days:
https://gitlab.gnome.org/Infrastructure/gimp-web/-/issues/216
However, single client accessing multiple mirrors at once probably increases the request pressure on shared infrastructure instead of decreasing it by reaching other peers.

Personally, I don't mind if GIMP download takes a minute or two longer. It would be great to make torrent client understand that those are backup links.

One option is extending the existing complex web seed limiter by adding the initial delay, and setting the default big enough to allow an average torrent to get some tracker or DHT results, and set up some peer connections. Then the bandwidth can be shared proportionally. If people who use Tixati as poor man's redundant or multi-server curl stand-in exist, they can set that delay to zero, and get the old behaviour.

Another option is adding some new logic to reason about number of peers found, bandwidth saturation, and so on, to use web seeds.

I do understand that initially this feature was used for exactly the opposite: three modem peers plus two cheap VPS servers equal more or less fast download and constant availability. But that was a bit different Internet. There are also rate-limited sources like Archive.org, in which case the result is more or less the same no matter you do.

Haven't found much about of standardisation of torrent client behaviours. libtorrent has max_web_seed_connections to limit them to 3 concurrent requests per torrent by default. That by itself, in my opinion, is the worst of both worlds, you neither get max speed from all when you need that, nor un-intrusive low priority secondary backup when you need that.

Obviously, the perfect solution is to add new field, something like url-list-intent: last-measure, to declare which of the opposite behaviours is expected by the hoster. Maybe starting that talk among client authors can starts the change.