A small number of reviews (this thing is huge). One question: would it be possible to have the bindings per-framework, rather than a single, long list? This is also what made PyKDE4 unwieldy. IOW, each Framework should ship their (optional) bindings.
We can put the tooling in ECM so that everything is in place for all the Frameworks. (This is how the current approach works):

My comments here are phrased as if this SIP-based approach was the solution eventually adopted (cppyy might be different). With that said...

This...

(this thing is huge).

and this...

One question: would it be possible to have the bindings per-framework, rather than a single, long list? This is also what made PyKDE4 unwieldy. IOW, each Framework should ship their (optional) bindings.

are related. Though the diff is huge, much of that is due to the 98 files in the PyKF5 directory (as opposed to the 10 that actually contain the crown jewels, plus the 5 template-related files). Let me explain...

Those 98 files are effectively two things:

1. The basis of the regression test suite for the tooling. In this sense, these rules (more or less) do just enough work to get beyond the fail-on-first-error semantics of the SIP compiler, and so are needed to allow enough of the syntax of the KF5 suite in the long list to be processed for me to feel comfortable that the tooling is "complete".
2. The starting point for the real per-framework rules that would be used in real life. In real life, I would expect the bindings to be packaged per-framework via ECM as you say, with each framework owner starting from the set of rules here.

We can put the tooling in ECM so that everything is in place for all the Frameworks. (This is how the current approach works):

The tooling in ECM would likely also host the shared rules (including the 5 files worth of template support) much as the current ECM does.

My suggestion would be to focus any review efforts in this order:

1. files in the top level directory.
2. possibly files the ./templates subdirectory.
3. __init__.py and CMakelists.txt in the ./PyKF5 subdirectory. Ignore all other files therein.

I hate to add a ping without any useful review, but I'm quite interested in this effort as I have a pykde4-based application which I would really like to get ported to the modern frameworks. Current distro packages of pykde4 are increasingly broken, and coverage of the existing bindings isn't sufficient to get the stuff I'm using (which isn't much, really) running.

Is there anything that someone like me can do to help with this?

In D7736#154948, @jasontibbitts wrote:

I hate to add a ping without any useful review, but I'm quite interested in this effort as I have a pykde4-based application which I would really like to get ported to the modern frameworks. Current distro packages of pykde4 are increasingly broken, and coverage of the existing bindings isn't sufficient to get the stuff I'm using (which isn't much, really) running.

Is there anything that someone like me can do to help with this?

Well, I only really got into this because I wanted to revive the Python support I added to Kate!

In all seriousness, I strongly doubt that a SIP-based solution for PyKF5 can ever be sustained without a dedicated maintainer, and my starting premise for my work was this was not a viable prospect. As hinted on the mailing list I've now spent the last 2 days with cppyy, and once I have made a bit more progress will post an update on that.

Thanks for the update; I'll follow the bindings list and work on getting cppyy into Fedora. Hopefully that will be relatively uncomplicated.