It appears type inference is failing in the simpler case of just referencing the init method directly. Ironic.
Is there some other way to write this that convinces the compiler it's valid and to use the intended init overload (specifically Int.init?(_ description: String))?
your problem (which is really the API’s problem) is that you are calling a conditionally-available overload on TryCapture called init(_:transform:), which is gated on Output == (Substring, NewCapture).
since LosslessStringConvertible.init(_:) takes a String and not a Substring, it’s falling back to the generic init(_:radix:) overload which takes some StringProtocol.
a lot of times LosslessStringConvertible.init(_:) gets implemented generically, which might be why you were surprised this time, but in this case, Int is inheriting the default implementation ss17FixedWidthIntegerPsEyxSgSScfc from FixedWidthInteger, which itself inherits from LosslessStringConvertible.
(for those keeping score, lib/SymbolGraphGen falsely believes FixedWidthInteger.init(_:) is implementing a completely different overload, which is a known issue. as always, we are severely limited by the sorry state of SymbolGraphGen.)