Moreover, java/byaccj appears to be a duplicate of pcr/byaccj, although the former is only available for x86_64, whilst the latter is available for both x86_64 and i686.

WRT tha "dead repositories" - who says they are dead?

the ones named like ~lukeshu and ~megver83, those are personal repos for each parabola team member - they exists for putting anything which is not yet ready for parabola, or is not interesting to any parabola user - they are like personal github repos

these things were put in place a long time ago - i am not sure why - i would agree that abslibre should contain only PKGBUILDs for packages which are available on the repos - but again they are harmless - none of those are in the default pacman.conf - AFAIK, they are only present in the git repo; so most people do not even know they exist

java/byaccj appears to be a duplicate of pcr/byaccj

that would be a bug i suppose - something could be done about those without discussion

The same argument goes for virtually all other packages, eg. why not have a separate repo for emacs, one for radare2, one for $PKG, because in most cases people don't use it?

I thought the whole point was to have several large, coarsely-grained repos of general-purpose tools instead of many tiny repos people have to keep their configs up-to-date enabling and disabling as they come and go, which sounds like a pain.
If people want to install related packages in one go or see related packages in one organised place, isn't this the job of metapackages/package groups?

Moreover, the many tiny repos paradigm goes directly against our current repo policies on the wiki.

I think libre and pcr should stay separate because they have coarsely-grained purposes: liberated packages from Arch/Arch32/ArchARM/Artix and an assortment of packages which don't fit anywhere else, respectively.
Due to this, the Java packages and the personal repo packages (if they are not dead) could just as well go in pcr, and the kernels could just as well go in libre, or pcr, depending on whether we classify them technically as liberated packages or an assortment of packages which don't fit anywhere else.
unmaintained and retired are essentially named synonyms of "dead"/"deprecated" and don't seem to contain anything particularly useful.
In this way, we'd have 8 less repos to wrangle, and a dozen or so less packages to maintain or leave to rot.

for completeness, there are a few more useless repos not
mentioned: (at least gnome-unstable, kde-unstable are presented
on the website) - they are probably abandoned arch repos

eg. why not have a separate repo for emacs, one for radare2, one for $PKG, because in most cases people don't use it?

if emacs had 20+ packages associated it, that were all useless
without emacs, that would actually make sense - the java repo
is probably like that - i would not be surprised if all of those
packages exist only to support one java application

I thought the whole point was to have several large, coarsely-grained repos of general-purpose tools

yes i suppose it is - core,extra,community,libre are those repos
- OTOH, those java package are probably not general-purpose
they are special purpose - kernels, nonprism, and nonsystem are
also special purpose most people have no reason to be interested
in them - applications like emacs may be interesting to a wide
audience (anyone who edits text files) - im not even sure what
the purpose of the java repo is (im looking at you, lukeshu) -
probably all of those packages could be deleted, rather than,
merging them - they all appear to have been put there by lukeshu
they may have been a work in progress, and never had a
completed purpose

If people want to install related packages in one go or see related packages in one organised place, isn't this the job of metapackages/package groups?

no those are to install many packages with a single command -
the packages need not be in the same repo

Moreover, the many tiny repos paradigm goes directly against our current repo policies on the wiki.

im not sure what you mean by that - off-hand, i would not
consider anything on the wiki to be policy - more like
explanations for how things happen to be, whether by convention,
habit, or legacy accident - in othe4r words, the wiki can be
changed to fit the reality, easier than the reality can be
changed to fit the wiki

I think libre and pcr should stay separate because they have coarsely-grained purposes: liberated packages from Arch/Arch32/ArchARM/Artix and an assortment of packages which don't fit anywhere else, respectively.

that is exactly my point - packages in PCR don't fit anywhere
else - the personal repos are for packages that should not be in
the main repos - they only fit "not in the main repos"

libre has more than only liberated packages - i wish that
it was only for blacklist replacement; but there is other stiff
in there too - i would like to split those out into a new repo

kernels fit well in a "kernels" repo - there once was
many more kernels - now that there are many fewer, i too
suggested removing the kernels repo; but megver did not want to
- that did not bother me - there is no practical benefit - most
people will never need to wrangle any of those - they can be
safely ignored - most people do not even know they exist - but
if people have a reason to modify pacman.conf, the octopi tool
makes it very simple to do

https://wiki.parabola.nu/Repositories does not even mention any of these small repos, which means making them is not policy, or the wiki is outdated.
I'd prefer the former.

My point is that if we actually applied the many tiny repos separated by narrow focus for specific tools paradigm, we'd end up with dozens of repos popping in and out of existence as packages come and go and we reorganise or shuffle packages around when we could just as well put them in a single large repo and carve out narrower groups of packages by assigning them to a package group/metapackage if that is convenient.

Sorting packages into tiny repos would be a massive waste of time, micro-managing what goes where, and there would inevitably be overlap and disputes over whether something should go somewhere, and confusion over where something actually is, especially for non-technical users being forced to use a separate tool just to enable and re-enable all these repos.

Other OS projects do this and it is an absolute nightmare trying to find something versus the way we already do it now, plus the organisation is confusing because of the overlap between categories.

There is no reason the kernels couldn't just go in the libre or pcr repo depending on how we technically classify them.
The kernels already fit there; making a new repo just for the kernels is artificial when they could just as well have gone there in the first place.
We are already a relatively small project and chopping up our repos into microscopic specks would be a waste of the resources we do have.