The goal was to kickstart this thread. Mission accomplished!

Qualcomm is the best-supported SOC for mobile devices, having tons of nice features and hence bering used in most of the top-line mobile devices.

However there are some downsides which I consider real dealbreakeres, and that is their baseband integration scheme.

The first thing you need to remember is that Qualcomm as a comapny is offshoot of the US military industry; it was first established to capitalize on communication and signals research done in the forces. The company still maintains close relationship with the government agencies and there is no doubt it includes some undesirable US-mandated features in their proprietary closed software and hardware.

This leads directly to the second point; it is impossible to use any communications features of a Qualcomm-SOC service without including in your kernel space closed binaries which have access to all of your memory and can do anything they like with the communication HW.... I believe this is somewhat undesirable

The situation here is exactly analoguous to Intel AMT coprocessor; The baseband processor in a Qualcomm SOC can interrupt and examine anything running on the main OM processor

Now as pointed out before, the only solution to this is to use separate baseband which acts like modem-only and has no direct access to the OM CPU. This solution is safe but it incurs some additional expenses and is not as power-efficient as an integrated solution.

Chen, is i.MX8 a realistic option, or is the hardware design way more complicated to the extent that it would pose a risk to the project?

Asking because I'd happily accept a device that is slower but can run a mainline kernel without blobs that tie it to a specific version. Having a separate baseband appeals too. I'd probably pay more for this.

Having said that, I'd settle for a "mostly free" qwerty slider - that's infinitely better than no qwerty slider!

Imagine that Android phones currently have 1 - 3 million lines of code in the kernel that is not released upstream. They have their own custom kernels! This situation is not reliable and the manufacturers know it.

This was the situation two years ago:
https://lwn.net/Articles/662147/

Unfortunately on the outside not much has changed yet. But if you listen to Greg K-H's latest talk on the subject it sounds a bit better:
https://youtu.be/RKadXpQLmPU?t=18m57s
(from around 19 minutes and forward the video has interesting details).

Kernel developer and maintainer Greg K-H and others have been actively "lobbing" manufacturers to begin upstreaming code. There is some hope for the future.

Seconded, remaining focused on the goal here (create a beautiful modern keyboard slider device) is already tough enough without adding in extra compromises to get full mainline compatibility.

Remember that there exists a lot of people who want such an Android phone, and aren't really interested in mainline linux compatibility.

For people who want that kind of thing, there is neo900 and purism device projects which they may already be a part of further diluting the possible backers for this device.

Regarding the high cost of OLED screens I just want to note that N9 display replacements, including controller and lightguide are currently selling for only 12€.

See ebay.

And yes, these are in fact OLED screens, I ordered two from different sellers, and tested them (The controller board was glued off-center on the first one and it didn't fit into the case)

Not realistic without a huge company/dollars backing it.

* iMx8 is not ready yet. The first units will start to be available in the beginning of 2018, and seeing how the whole electronics industry is having a hard time to keep low factory lead time, it should need some time before them being easily available on small orders. Software support will probably take a lot of time too.

* Chen's project is possible because he wants to reuse an existing and validated PCB and "just" adding the keyboard and some tricks. Designing a new PCB is a lot of work, as can be seen with the time it takes to do it by the Neo900 project or by Purism (delivery in January 2019). You can see how chen's own Moto keyboard project has already been delayed to match the expected quality to see that the project has to be kept reasonable to have a chance to be fullfilled

@Chen, I am a little bit irritated about you regularly questioning basic premises, you reasonably set for this project months ago. Surely doing checks & balances is basically always a good thing, but re-evaluating fundamental cornerstones of this project again and again will lead (this project) nowhere.

From what I gathered in this thread months ago, your plan (and IMO the only feasible route for a project initially producing 3000 to 5000 devices, while hoping for more) is:

1. Take an existing Qualcomm design as a basis.
2. Create a new housing based on your Moto-Z keyboard, with a replaceable battery under the keyboard (to achieve a proper weight distribution, when the hardware keyboard is slid out).
3. Adapt the existing PCB slightly to accommodate for the new keyboard connector and the relocated battery. Do absolutely avoid changing any high-frequency PCB traces, i.e. those connecting the SoC with the RAM, the analog WLAN circuitry, the analog Bluetooth circuitry and the mobile network circuitry. Keep all other changes to the existing PCB as minimal as possible, otherwise you will likely end up in months of hardware debugging, PCB simulations and the costs for a PCB design expert (or even worse with not properly working devices). We have seen that many times in the last 10 years, e.g. Openmoko GTA-01, -02, -03 and -04, Neo900, Pandora, Pyra etc. with only half of them succeeding after years of delays.
4. Deliver the device with LineageOS preinstalled; this requires basing on a design which is already supported by LineageOS, otherwise you will be drafted into significant kernel adaptation work, which can easily stall this project for many months, too. Although some adaptation is likely to be necessary for the hardware keyboard, which is more than enough, IMO.
5. Deliver the device with an unlocked boot-loader or (if regulatory requirements demand that) with an easily unlockable boot-loader (from within Android/LineageOS, e.g. as in Xperia X's latest OS release).
6. Negotiate and settle a SailfishOS option with Jolla, before starting the crowdfunding campaign for the device; again low-level software adaptations are required for this, but having an Android-kernel from LineageOS supporting your device will ensure that all pieces are already there, they "just" need to be integrated into the "Android-kernel" used by Jolla (taking weeks to months). Hence choosing a design as a basis, which is somewhat similar to the Xperia X (i.e. Qualcomm Snapdragon 65x SoC, maybe also some of the peripheral chips, e.g. Bluetooth etc.) will reduce this adaptation work a lot.

The only other option to deviate from the base design, which does not require tremendous efforts, if carried out carefully, is the display: Please do not pick any higher resolution than "FullHD" (i.e. 1920x1080/1200 pixels), rather go for a 1280x720 px display or something slightly higher (e.g. 1440x900, 1600x1080). Very high resolution displays have significant drawbacks, e.g. (in descending order) power consumption, drawing speed (2D and 3D, due to many more pixels need to be drawn), maximal brightness, longevity etc.
Side note: A matte ("non-glaring") display (option) would be nice (I personally prefer them a lot), but requires a non-HighRes display (i.e. 1280x720 on 5,5" to 6", at most 1440x900 on a 6" to 6,5" screen), as the grainyness of the matte surface interferes with the extremely tiny pixels of HighRes displays, leading to an "unsharp" visual impression.

Chill olf, Chen isn't an idiot and knows the costs of developing a custom PCB.

You also seem to be misunderstanding exactly how the device adaptation process goes, generally speaking the OEM will give you an android aosp/caf adaptation which wouldn't be so bad building LineageOS from.

Also on the Sailfish OS porting side, the problem is the design of android doesn't have an 'android-kernel' and instead tends uses userspace driver blobs. As before I warned against being too similar to the Xperia X due to poor kernel support for some of its devices, particularly the Wifi+Bluetooth+FM chip. So no, just because something is well supported by Lineage OS doesn't mean all the pieces are there at all.

@r0kk3rz, yes I do feel confused and a bit worried about a couple of continuously recurring points in this discussion thread. Maybe using "irritated" with all its possible connotations startled you, but Chen posted hardware specifications 2017-07-28 and a couple of more details in the following days, so everything seemed to be nicely set back then. But in the four months since then, all these premises were questioned again and again; by others, but also by Chen himself (at least this is how I interpreted his questions posted here). Maybe I misinterpreted the aim of these questions, but they clearly contradict the cornerstones of this project as set in late July / early August 2017.
But actually I would prefer @Chen to express, if these original plans still hold true or if they are reevaluated (or if his questions / considerations are solely addressing "future devices", as he once stated).

By no means I would consider him being an "idiot", actually many aspects of his statements and efforts made me trust him a lot, which rather contributes to my current confusion. And maybe I emphasised the aspect of PCB changes too much.
What I wanted to clearly get across was, "Please keep all changes as minimal as possible, as many have underestimated the delays and costs they cause in the past, and a couple of prospective projects died due to this."

Well, I know. Actually "wouldn't be so bad" is a nice way to put it, which may still bear significant pitfalls in contrast to having something working in the first place. But discussing this is irrelevant, if the hardware is still set (and yes, I shouldn't have brought this detail up yesterday).

Look, these are technicalities I tried to avoid, when calling the whole non-mainstream kernel and (partially user-space blob) drivers (i.e. the whole low-level software stack) "Android-kernel" (explicitly in quotation marks): This whole foo has to be adapted to be used by libhybris and Mer / SailfishOS, which takes significant time and efforts.

Oh, I missed that: Thanks for pointing out, that a similar Wifi+Bluetooth+FM chip is rather a disadvantage.
OTOH, SailfishOS supports that already (although with some issues / lacking features), while support for alternative peripheral chips has to be integrated first. So this also is a question of time-to-market and costs (and again irrelevant, if already chosen).

Well, on this point I disagree even on the technical side of things: While I deliberately put the "just" in quotation marks, a hardware well supported by LineageOS will provide many pieces of low-level software to be reusable (some needing to be adapted) without legal and business interactions to get access to and the right to distribute the BSP (board support package) etc. This is a big plus in terms of time and costs involved, IMO, if similar kernel versions for SailfishOS and Android are available. Maybe the Android 6 based release with a better fitting "Android-kernel" version (for SailfishOS) was still published under the CyanogenMod label.