Is the goal to have a TOH for mass production or something that people can build only for them (by e.g. ordering PCBs, ICs, and 3D prints and applying some soldering)?

In either way there can easily be couple of variants of the electronical side, one with a simple keyboard IC and one with a microcontroller. From the kernel's point of view they can even obey the same commands over I2C although later on the microcontroller could do much more with a dedicated kernel driver.

Certainly there can be variants of the mechanical side as well but I haven't seen any progress in the other thread about that. If there will be an order of 100000 units, certainly anything can be designed but there are much more limitations when ordering a PCB and a 3D print just for a single device (and this is the approach I would like to follow).

I've ordered a simple model from Shapeways.com but it's much more complex to have moving parts in it (e.g. the buttons and the sliding mechanism). Besides that I don't have any experience on the mechanical side and I would like to see some concrete steps about actually creating a physical keyboard. The actual button layout etc. can come much later and in different forms.

Playing a devil's advocate here - it doesn't have to make it easier, as long as it doesn't make it harder. The microcontroller's SW can be written to emulate any chip in the known universe, including those thatk Sailfish already knows and understands. Which might even mean NO extra effort on the Sailfish side. Since we do not know yet which ones those are, using a microcontroller makes sense to offer that flexibility.

AFAIK TCA8424 can also be used without I2C HID using a regular /dev/i2c. The chip is I2C HID Compliant. Not I2C HID only.

The whole point aperles had was that using a microcontroller makes it easier, but for me it seems that it doesn't.

If the keyboard is just a keyboard and nothing that the keyboard chip can't handle, imo using a microcontroller isn't worth the extra micro amps and effort.

If you want to go for low power, then a CortexM is way too much, and you can find a lot better.

Remember that we are simply trying to create a keyboard OH here. So basically, what we need is:
* a few kb of program and hundred of byte of ram only is needed (less than 100 keys state to save...)
* 1.8V compatible I2C bus
* 1 output for the interrupt line
* about 8 inputs and 10 outputs for a 80 keys matrix keyboard
* 3 PWM output to drive a full color backlight
Or 1 PWM output do drive a dimmable single color backlight
Or 1 output to drive an on/off backlight

Note : I divided with 8 inputs as interrupt on change are availlable on ports that are usually only contains 8 pins. If there are more, then it would be faster to have a 10 in / 8 out split.

So a cortex have so much peripheral that wouldn't be used here, and a 32bits core where we don't need it, so that we can find a better fit in the range of microcontrollers.
As an exemple, in a quick search on the Microchip PIC18 range (8 bits), you can find some that come in SOIC package (so easy to solder), with 22 I/O, and I2C bus, that comes with very low power requierements (what their marketing call "nanoWatt": sleep mode at around 700nA, and very deep sleep mode at 9nA, and run at 5.8µA). The first result was the PIC18F47J13, but its supply voltage is 2V mini, not 1.8V which would make it easier to interface with a 1.8V I2C bus.
Atmel and other silicon maker should have a load of this kind.

I can't find a use for DAC, UART, SPI, USB, or LCD in a keyboard half, but they can be usefull for other projects. The only thing that could be used in the list are the ADC channels for a gaming keyboard with analog sticks.

But at the end, a lot of work is involved to use a microcontroller (an additional hardware for the programmer/debugging probe, a compiler suite, ...), where we already have a lot of problems to solve in the mechanical sliding mechanism, the keys material, the layout, the driver in the Jolla, ...

So even if we can have better performances, capabilities and power consumption with a micro-controller, it may be more reasonnable to start first with a dedicated controller that have upstreamed drivers in the kernel tree, and when everything works, then take a look at how we can improve it using a micro-controller.

Of course, this is only my opinion, as by experience I usually tend to want to make optimal things and miss the fact that a sub-optimal solution was easier/faster to set up...

So, it has been a bit quite here.

Primarily, I am waiting for the Launchpad, which is halfway out of China... When the launchpad is in, I can connect the microprocessors with my computer and program the keys.

While the Chinese government is checking this piece of electronics for bombs, I have started learing Eagle Cadsoft! This I can recommend to anyone! With this program you can build the files to send to PCB-makers. Also for DIY work this is quite handy. Download it and watch this tutorial, you're an instant pro.

If you are learning a new application for electronics, I need to recommend Kicad. It's open source and has not limitations unlike Eagle. Eagle limits your possibilities related to commercial projects (unless you pay them) and e.g. the size of the PCB (unless you pay them) and the layers used (unless you pay them).

For first designs it's nice but it's less nice when you start the next bigger project and realize that the free version limits too much.

I already have a full version! (and in modern days, how hard is it to get software?!)

Okay, Launchpad will be in the mail tomorrow

As I am the proud owner of a windows computer that does not possess the ability to compile a Mer image for the RPi, can someone with a Linux machine do this for me and make an Win32-image of that SD?

Whoever is first, wins 5 points!

Is your Windows computer capable of downloading VirtualBox and Debian or another suitable Linux distro?

Trust me, it's a one-off investment (of time) that will pay off many times over!