I'd actually say for both but if anything %post is the most important one since that's where you would put code that wasn't easy enough to put into a ./configure/make invocation. Usually autoconf will do a good enough job catching the variation for you but %post will always just be %post and always be something probably unique to that distro.

As I mentioned, technical decisions are not the same as distro-specifiic customizations. Moving something from a folder to another is not distro-specific: it's one choice that was taken by that distro, but that nevertheless could be applicable to others. These are the kinds of things that go in %post, and making all of those decisions again rarely brings any benefit, only endless bike-shedding.

Another example would be building applications/DE's with Wayland support or not

That seems like a decision much better taken by upstream than by the distribution. It also does not require writing new packaging scripts in any meaningful way.

the entire fedora-release package, the lsb stuff

That's not difficult to handle at all, and still a measly fraction of starting from scratch.

kernel configuration, etc, etc.

The kernel spec is the perfect example of what you don't want to write from scratch. Changing the kernel configuration is not a problem at all.

Even just to remove branding can take work.

It shouldn't since no packages should include branding in their default state. All the branding should be in separate packages clearly labeled as such.

And we don't disagree about that being an available option, I'm just saying you're being premature in assuming that just because it's a new PM that it must be redundant just because it's not as radically different than Nix.

You're making a pretty big assumption there. You're assuming: a) that the PM was the center piece b) they're particularly good at public messaging and c) that if information is worth having it would just throw itself at you.

: On that last one, you can follow that logic you've made a best effort to gather information about what you're talking about but it doesn't sound like you've done that here. If it's important enough to have any opinion on it's important enough to at least kind of try to have a somewhat informed opinion on it. If you can't force yourself to care that much, one has to ask whether you really even need to form any opinion on it whatsoever.

I've looked at their package management section in their documentation and there's absolutely nothing noteworthy, and a bunch of missing commands and features that I use in other package managers. You cannot expect me to go looking for features that may or may not exist but are not documented or presented anywhere, just to entertain the possibility that there might be a small justification for writing packages from scratch. It makes no sense and doesn't seem like a worthwhile use of time.

You're not supposed to guess, you're supposed to either at least kind of look into it or not form an opinion at all.

I did, and that's why I mentioned I saw nothing noteworthy.

You've spent longer arguing with me than it would take to just copy it to a USB drive and play around with it yourself.

I have seen no information that makes me interesting in playing with the PM at all. Nada. That's what I've been trying to say. Your assumption that it could be good and interesting is nice, but not backed by any evidence available.

Seriously, even just half an hour and you could claim to be at least somewhat familiar with it.

I have many things that I need to be familiar already to add a package manager that doesn't seem to be bring me anything of interest, specially actual packages.