Yes, the feedback that would tend to get addressed was always related to actual HW issues, and the issues listed in your blog article seem to all be failry superficial without any effect in practice. Eg. eMMC and DRAM is a commodity, various phones batches likely got different components based on what was available. I know for sure that my pinephones have different eMMC chips from different vendors that have different real speeds, so got to 78 MiB/s at DDR52 some just to 50-60 MiB/s, etc. DRAM will probably be a similar case just based on the fact that some phones got 2GiB and some 3GiB on the same PCB.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.