[Google Pixel 3a ROMs, Kernels, Recoveries, & Other] gee one:
The pixel series are paired up with the xl/non-xl version (marlin/sailfish, walleye/fishy, crosshatch/blueline, sargo/bonito). The repo I am using is from https://github.com/lineageos/android_device_google_bonito

You can see the changes here: https://github.com/gee-one/android_device_google_bonito

As far as I know, the squeeze sensor and esim aren't working. The camera could probably easily be fixed by a real developer.

I don't know what is holding up pixel development. There are A/B treble builds for other phones, so it's probably not a technical issue. Lineage is a volunteer project, so maybe none of the developers/maintainers wants to play with the pixel when they can have a galaxy note 11 that 3-D prints ramen noodles or a X00TD that has a catchier code name. I'm not even sure what phone that is, or if it even is a phone.

I'm not a lawyer, but yes, all the proprietary bits that go into the rom come from the stock rom. There is an extract-files.sh script that can either pull from a running phone or from the stock image (after unpacking).

For comparison, these repo have scripts that pull the blobs from the stock rom, although these are more geared towards aosp, and not lineage.

https://github.com/anestisb/android-prepare-vendor

https://github.com/chirayudesai/android-prepare-vendor/

I'm also not a real android developer, but as far as I know, there are a few approaches to the vendor files:

One is to use the stock vendor image and just flash system/boot/dtbo/vbmeta images. The vendor image wouldn't be flashed with the rom, but would just use whatever was on the phone, presumably stock. I think this works and provides most, if not all, of the functionality. I think I tested this, but I can't remember how it turned out.

Another approach is to build the vendor image with the rom. I prefer this approach, but I can't say if it's better or worse. I use a prebuilt vendor image from the the google driver binaries that are used to build aosp (see link below). You could also, in theory, build the vendor image from the component files, instead of re-packaging an existing image.

https://developers.google.com/android/drivers

GSIs aren't the final solution. There are still some phones/custom roms that release device specific builds because GSIs didn't work as well. Descendent OS had a few like this, although I don't know the technical reasons the device specific builds.

Also, in qberry (Android X/10) there is a product partition and dynamic partition sizes. This might complicate building. It looks like lineage is adding changes in 17 to accommodate product and ODM partitions. I'm not sure what they acheive or how they improve things. I'm sure there is a reason, but I just don't know it.

The first build is the hardest, but after that, a lot of it can be automated.

The monthly maintenance would include any changes to aosp that should get pulled into lineage. If we had an official build, this would be done by the maintainer.

git does make it easier to apply changes on top of branches, so any new changes would just get merged onto the existing branch.

When there are new releases, such as qberry, it is a bit more work to update the build tree for the new version. I tried to build los 17 last weekend, but it just bootloops, so there's still a bit more to go before it's usable.