deb packages still in focus

Not intentionally, no. If you just use an overlay filesystem and regular dpkg to install stuff you may wind up with a situation like this quite easily though.

Install package P1 with dependency D with sd card S1 as the write overlay, insert SD card S2, install package P2 with the same dependency D, dpkg sees D as installed and doesn't install it on S2, remove S1, now you have P2 but no D.
Maybe I forgot to mention, but the dpkg index would live inside the overlay as well. The idea is to make a chroot environment with the benefit of not having to duplicate anything that's already on eMMC. I also mentioned that probably one overlay per SD card would be needed.

dpkg would only see what's on one overlay when the user (or some script) chroots to into it. And then when a package is installed it will forcibly land in the same overlay.
To be honest it sounds like a system an individual could get working with a bit of work, and be suitable for that individual.
It won't suit all use cases that PND and DBP are intended to cover though. One example: people with a windows machine who want to be able to use the SD card in the windows machine. For many people being able to use FAT based filesystems on their SD cards is going to be be important.

This was supposed to be not a general DBP/DEB bashing xD

As announced last week I was working on the "OBS - OpenBuildService" for the pyra this week.
I was able to rebuild nearly all debs from in OBS (kernel build is still running).

I'dd be glad if some of you would get a look and comment if this software would be suitable for our purposes.
I set up a public test system for you (only testing). Don't mind it's slowness ;)
Feel free to register and test it out (in your own home projects).

As you may notice, you cannot simply use deb source packages and import them. To simplify this you can use this:
Of course when building own packages this is not nessessary...

Feel free to ask, if you want to know/test something.

# OBS url

# project with pyra packages (after login)

# repo url

# gettings repository to work (on pyra/pandora/devboard)
root@pyra:/etc/apt/sources.list.d# cat
deb [arch=armhf] ./

root@pyra:/tmp# wget
apt-key add Release.key​

Even more Info:
# wikipedia

# portal for gettings to know the software (WARNING! There is some very old documentation, especially for the debian stuff)

# usefull page about deb packages in OBS

# usefull page about cli (git like commandline)
Well my devboard appears to be dead... So no chance on my end.
Let's be honest here, if you remove any kind of essential storage media while it's still mounted (a.k.a. you don't know what you're doing), you deserve whatever is coming to you. That's like removing the HDD while your computer is running. But at the same time, if the whole rootfs is on a removable SD card, I could also and pop it out by mistake, and lose everything that was stored to RAM eventually, everything can't use disk I/O anymore, and eventually the desktop crashes and I have to restart or reboot. No biggie. But ejecting my SD Card would be rare unless the Pyra is going to use those SD Card holder press-to-eject springs, lol.

What we should really have is the whole RootFS with essential packages installed on a NAND or something, then you can mount/overlay non-essential packages from the SD Card. Since you can't really unmount NAND without an explicit command via root, that makes the most sense.

I also really don't think most of our Linux power users here, which is like 99%, are really going to give a damn about ease of use and over... well... power.
Also, believe me when I say it's really hard to corrupt certain file systems like Ext4 and Btrfs by unmounting. If anyone here is worried about file system corruption, modern file systems handle this type of stuff well. You can always fsck something to try and fix it, no problem.