Are we comfortable with breaking the ABI for this?

If so, this will need an SO version bump. Then there is a bunch
of other things that might use a breaking upgrade if we're doing this.

What reasonable options do we have that won't?

Introducing new API variants that work with the new types.

Perhaps extending this struct with new 64-bit values (while
keeping the existing ones) might also work, I'm not sure.

Adding new/duplicate API seems like not a great solution to a long term problem. Extending the struct would work, but again it's a bit of a fragile fix for a long term issue. I'd probably be OK breaking ABI but I could be convinced to keep it. :)

I'm not for or against an ABI break, but in case we do it, it's a bigger deal;
It needs coordination and completing the At next SONAME bump list in
docs/TODO.

Also, before doing an SO bump, it'd be useful IMO to do a non-breaking
release with the fixes since 1.11.0, including the pending OpenSSL 3 PR: #1207.

I'm thinking putting this change behind an internal macro (e.g. __LIBSSH2_ABI_BREAK_NEXT) reserved for debug builds, alongside a CI test. This would allow to merge this early (now), and potentially allow to prepare new ABI breaking changes in the source, and release/enable them when everything is ready.

Anyone opposing this?

Edit: For documentation the pages could be duplicated into a modified, not distributed copy. Perhaps.