Adam Reichold

We have a general need for fallible conversion traits but we are lacking the people to tackle this concurrently with the `Bound` API overhaul, c.f. #1813 and #2782.

Another question is whether GitHub merge queues support and whether we use something akin to bors' roll-up merges to better handle multiple PR landing simultaneously.

So what are our settings for "Build concurrency" and "Merge limits" as described [in the docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)? Do we build concurrently? Do use groups larger than one?

> It should also be possible to create a new type that has the buffer protocol and pass that to `PyBytes` without copying. Considering the resizeable `PyBytes` might be XY...

> the drawback would be extra generic code bloat by having all the .downcast() implementations for many different Bound types. We would still see an increase in LLVM lines, but...

A default-on feature gate seems the more reasonable approach IMHO.

Generally speaking, some amount of overhead is unavoidable due pervasive shared mutability applied in Python which requires us to use interior mutability patterns to enable safe Rust code from obtaining...

Note that we should be able to get there in 0.22, i.e. the `gil-refs` feature will not just silence deprecations of the old API but the old API and the...

> I also wonder whether we could already move the global Py reference counting to a dedicated thread which attempts to wake and update counts at intervals, rather than doing...

> Or we just include it in 0.21 but call it experimental and aim for complete and documented support in 0.22. Maybe that's fine. I'd say `experimental-inspect` as a feature...