[Lenovo Yoga Tab 3 Plus ROMs, Kernels, Recoveries, ] vladimiroltean:
Not a dumb question at all, since there's tons of misinformation on the topic floating around.

As you may know, what is commonly referred to as project Treble is basically a separation introduced in Android 8.1 between the core platform and the vendor-provided binaries necessary for the hardware support. Initially Google did this to reduce the back-and-forth with silicon vendors such as Qualcomm when developing new Android releases, so they could work in parallel.

Unofficially, the idea of Generic System Images (GSI) caught on, in the sense that devices which are completely compatible with the requirements of Treble might be able to boot such a GSI while keeping their own vendor-specific files. XDA user phhusson (Phh) is the most notable person who has so far put forth self-compiled GSIs for AOSP, LineageOS, Omnirom and RR.

There are many requirements for a device to be compatible with project Treble. There is a Vendor Test Suite (VTS) that tests for most (but not all) of these, but here are the most important ones:

The vendor-specific files must be compiled with a separate compiler toolchain (called VNDK) than the system/platform files. The goal is for the dynamic linker to enforce rules at runtime such that vendor files do not link with system files which may have unstable API/ABI, and viceversa. There are some exceptions in both directions that are mandated by Google. In this category of vendor files are included both open-source files (HALs etc) and proprietary files (which we distribute as blobs).

Have a dedicated partition to keep these vendor files, such that reflashing the system with a new GSI does not lose them.

The following pertains to our device:

We are able to compile most of the open-source hardware support files with the VNDK toolchain. There still are issues with the hwcomposer HAL necessary for the graphics stack.

The proprietary files are taken from the latest Lenovo stock release (June 2018, Android 7.1.1) which is far from being compatible with the requirements of Treble. The proprietary files are also a big question mark right now, because we cannot enforce the dynamic linker namespacing (to figure out what are the runtime breakages) because we couldn't compile the hwcomposer with the VNDK yet.

We do not have a vendor partition.

Being compatible with Treble, as tested by the VTS, does not automatically mean that a GSI will run well.

For instance, we are users of the ro.sf.hwrotation=90 property, which adjusts for our device's display panel, which is portrait but mounted in a landscape device.

Currently only LineageOS implements support for ro.sf.hwrotation. Therefore, a GSI of any other ROM would have the display rotated by 90 degrees compared to the touchscreen, camera and the sensors. Our vendor image can't check for what system image is loaded and adjust its behavior based on that.

The above is just an example. There may be many more other obstacles lying ahead, before a GSI may run reasonably well on the device.

On the other hand, technically it is possible to repartition the devices. The system image can be shrunk by enough as to fit another partition for the vendor image in the free space. I have already developed a proof-of-concept TWRP zip which is able to switch back-and-forth between the stock GPT partition table and one that is Treble-compatible (has the extra vendor partition).

When talking about safety, the TWRP zip takes all safety precautions, but nonetheless, the unexpected can always happen. On the device there are some "critical firmware partitions" which hold the code necessary for the boot flow sequence (mainly the bootloaders). If the device's boot flow cannot reach fastboot, it'll enter a so-called Emergency Download Mode (EDL), where intervention with a dedicated flash programmer (mini-program that is loaded in RAM and reflashes the storage) and Qualcomm QPST-compatible software is necessary in order to restore enough of the partitions on the device as to be able to boot to fastboot.

We call devices that only boot to EDL mode "bricks".

So far, de-bricking a device relies on flash programmers that are either released publicly by the device vendor, or are exfiltrated ("leaked") from repair services.

Applied to our devices, only the YTX703L is known to have a leaked flash programmer with which it is possible to restore from EDL mode.

Therefore, while the repartitioning script in TWRP is as safe as it can, there still exist inevitable risks of bricking for the YTX703F.

The requirement to have a vendor partition and the one for the vendor files to be properly isolated are completely orthogonal to one another.

Initially we wanted to repartition the devices now (during the switch cm14 -> lineage15), so as to satisfy at least the second requirement (having a vendor partition) while exploiting our only chance to have minimal headaches with migrating users between incompatible builds. It is very unlikely that I'll ever want to manage a lineage15 <-> lineage15 transition (where everything "looks the same but doesn't werk") just for the sake of repartitioning.

You should also know that it is possible to disable the dynamic linker namespacing. This is what all lineage-15.1 devices that don't have Treble-compatible vendor files (proprietary and open-source) do. This means that Treble compatibility might come incrementally, since the dynamic linker isolation would need to be handled on a library-by-library, executable-by-executable basis. Meaning, one day, perhaps one year from now, perhaps later, the hardware might satisfy the requirements for Treble.

But trying to fix the many linker issues only makes some sense if the devices had a vendor partition. Otherwise we're talking about many hundreds of wasted hours for absolutely no end goal.

How did we even get here, and who might help?

Well, Qualcomm did release their final tag for our SoC (msm8976, aka msm8952_64) on May 1st this year: LA.BR.1.3.7-05010-8976.0 (https://wiki.codeaurora.org/xwiki/bin/QAEP/release)

So in theory, by looking at the numbers (08.01.00), yeah, it should be Treble compatible, but it isn't. As I said earlier, we have blocker issues compiling the hwcomposer HAL with the VNDK, and we haven't even ran a full build compiled with the VNDK and with the linker namespacing enabled yet, as to even estimate how much work we're looking at.

On top of that, I can't find any other OEM who is using the msm8976 and who picked up the 8.1 Qualcomm tag for a stock build. See a list of devices here. So taking the proprietary files of another msm8976 Android 8.1 device, to reduce some of the work, is out of the question.