Is it only me, who think that package management could benefit from server / client architecture when it comes to command line interface?
Also, it should ( in functional programming there’s thing called side effect ) list all side effects, with possibility to rewind them with some checkpoint-tree architecture system. Also possibility of having multiple versions of some packages installed at once, would be awesome when it comes to libraries.
That contradicts the whole rolling release philosophy, i think.
I don’t get what you mean by this. If you mean interactively, I think that’'s a TUI and in my opinion it would be a bad idea. Because what happens when your internet dies? Or your ISP has a problem? Or the AUR gets DDOSed again because now a lot more people are constantly accessing it? Again.
It is already pacman is the client - tallking to a configurable mirror
pacman is transaction based and the transaction is only started when all packages is available.
If you then break the transaction - ctrl+c - or pull the plug - bad things happen - no paradigm can control that.
With your mindset you are going to love https://nixos.org/
The Arch Linux philosophy adopted by Manjaro is K.I.S.S - and that means - only one version of libfoo.so can ever exist and pacman is very good at that.
I started using Arch but as a matter of convenience I started using Manjaro.
From time to time I look back - run an Arch install or EndeavourOS having a brief look - under the hood it is mostly the same but Manjaro stands out - always.
Currently I am running bleeding, bleeding edge
$ uname -a
Linux tiger 6.5.0-rc5-next-20230809-1-next-git-08441-g21ef7b1e17d0 #1 SMP PREEMPT_DYNAMIC Sun, 13 Aug 2023 15:41:24 +0000 x86_64 GNU/Linux
I don’t mean package servers…
I think of package manager running as daemon that recieves tasks from terminal command line client.
I think that current situation doesn’t handle the internet outages either, as it disconnects and you must rerun the command.
Also, if all packages are signed, they can be transfered by p2p protocols such as bittorrent, which would be big advantage in case of DDoS attacks.
The internet or power outages are a major problem. And the situation with the mirrors of which only 1 is used. Generally, it is a simple and imperfect and somewhat error prone package distribution model. But manjaro is based on arch and i think you are barking at the wrong tree. Such major changes should happen at the arch upstream and all of the OSes based on it…which will never happen. So it is more or less take the arch way or leave it and go to debian or snaps…which have their own plethora of imperfections. Here…is at least kept simple.
By the way the packages are signed. And DDOS is not that of a problem with the repos, because you can change mirrors. It more of a problem with AUR, but here we have the disclaimer “it is unsupported” 
p.s. in theory, you can configure pacman/pamac to use external downloader, something i2pfs capable. An configure them to use one custom, not changing mirror. An then set a custom mirror on i2pfs. It will be an interesting experiment.
The current system is already client and server.
Pamac is the client and installs packages with the libalpm library (the server, so to speak).
I don’t understand what you mean by this:
What does this have to anything with client/server? Arch and therefore Manjaro does not work that way: it fundametally always uses the latest version available, hence the name rolling release.
Selected packages are still available (e.g. ffmpeg4.4) in multiple version.