I understand that Ubuntu was an example – but my counterargument holds for Fedora and OpenSuse and PCLinuxOS as well.

You raise valid points against slackware, but forget the points in favor of it. Slackware follows the installation instructions of upstream projects more closely than any other distribution (meaning it has the lowest degree of upstream/downstream conflict), it has one of the cleanest bootup architectures out there, it never installs anything you don’t explicitly tell it too (the kind of users I am targeting consider that a feature, not a bug) – 99% of it is easily modified shell scripts, making it truly simple to customize.

These are valid good points, they don’t make your points invalid – they just mean it’s aimed at a different kind of user than for example Fedora is. My target user (at least initially) is more tech savvy, they want the fastest possible setup – absolutely optimized to their unique work habits – but they also don’t have time to recompile every single library or app and they don’t have hours to spend trying to figure out dependencies by hand. They probably had some past exposure to one of the BSD architectures and liked them.

Remember MacOSX is also built on a BSD architecture, it’s a surprisingly good underlying design for a desktop OS. But I personally feel the desktop BSD systems have a fatal flaw – they all use kernels built for the upstream BSD systems, which are highly server-centric kernels, that don’t perform well under desktop use and don’t support desktop hardware well. That’s why Mac created their own kernel, and why we have Darwin.
But Darwin has the Mac problem – a very small driver selection.
Slackware marries the Linux kernel which has awesome driver support and very good designs and optimization options for desktops with the sleekness of the BSD systems, Kongoni is a desktop optimized version of that, with the missing piece (ports) added.

It’s really not even that revolutionary an idea. To be honest Kongoni is probably more competition for the PC-BSD userbase than for the Ubuntu userbase, at least for the first few relases, but that’s fine – they are the kind of users I want to target, heck they are the kind of users I am.
Besides my showing in the post that systems like embedded platforms built on busybox really couldn’t benefit from being build on those systems – I just showed you another one, the Kongoni type of system, which is aimed at a completely different type of user. A user who wants fine-control over his computer and who does not want it to install anything he didn’t request, who wants the very compile-time options of a package to be within his grasp to optimize without losing the flexibility of easy upgrades and uninstalls.
Basically, the kind of user who finds ports-trees to be a wonderful invention, but also want the hardware support of Linux, the power of the GNU tools and the freedom of the GPL.

There may not be as many of those as there are secretaries, but there are more than enough to make me feel my project is both needed and valid.

On Ubuntu being a fork of Debian, you have to understand that Ubuntu isn’t really a fork in the traditional sense. Not like SuSE forked from Slackware. Ubuntu starts from a Debian base and merge their changes every six months. The Ubuntu maintainers also try to get as much of these changes into Debian to reduce the work load for the next release.

Using Ubuntu as an example for satisfying use cases of custom distributions was an example, for the record. I could’ve used Fedora or OpenSuse in the statement too. I’d like to see your special use cases where you wouldn’t be able to use any of those distribution’s packages though. I still say that you’re making a mistake in choosing slackware as a base over those systems. It has weak release management, a weak package management system and a weak support cycle. There are much better choices, imo, you can make in terms of what you want to base Kongoni’s underlying software on.