Is there actually a discoverability problem for GNU ELPA packages? After over 25 years of Emacs use, I think discovering and trying out new packages and features has never been easier. I really don't miss the old days of hunting around various ftp servers trying to find the latest and current version of some library or package.

I know for me at least, as soon as I need some new functionality (setting up for a new language, needing to do something new, looking for alternatives etc),  or just check out what new feaqtures, packages etc are available, one of the first things I do is M-x list-packages. This gives me a list of all the available packages from all the package archives I have listed. The source (archive) for each package is clearly identified and since I added all the additional archives, I know what the differences is between them. If a package is available in both GNU ELPA and another archive, like MELPA, I will typically select the one from ELPA, because rightly or wrongly, I expect it to be more stable and comply with GNU philosophy. I might later change (as is the case for org because I want both the latest org version and the additional packages from org contrib).

The only real issue I see is the apparent confusion within the GNU Emacs project itself regarding ELPA, what role it should play and how it should be maintained. This is based on some of the threads seen in this list. Perhaps the below has already been done and if so, then we just need to make that information more prominent or accessible and point people to this information when questions regarding ELPA arise. Anyway, I think the following might help

- Define the rationale and objectives that underpins ELPA. Forget about historical context and focus on current context.

- Define what should be and what should not be included in ELPA. This should be based on objective criteria

- Define an ELPA custodian responsible for deciding whether a package should or should not be added/removed from ELPA. This custodian should be able to appoint a team of people who can assist. There will probably need to be some appeal process as well, but I'd keep it simple to begin with.

- Ensure the custodian is supported and is seen as the 'official voice'. Any ideas, concerns or need for clarification re: policy etc should first be discussed with the ELPA custodian (they may delegate some of the work, but announcements, decisions etc should come from them). Note that this does not mean they are the decision maker or benevolent dictator - they are just the spokesperson and what they say can be take as the official position.

- Develop guidelines on when a package or library should be included in core Emacs i.e. is in the Emacs source code distribution and when it should be in ELPA.

- Decide if we really need the ability to have some sort of category or split i.e the 'blessed' and 'neutral' packages (I'm not convinced this is a good idea).

Some of the above steps will be challenging and likely involve considerable debate and things may evolve and change over time. However, it would at least provide a more consistent base from which to develop and expand. Once this is done, a review of existing ELPA packages and GNU Emacs libraries/packages could be performed to decide if the current split is correct. Some things may need to move from ELPA back to Emacs and vice versa. More importantly, once we have this level of clarity, it should be easier to decide whether there needs to be more done to inform and educate the wider user community regarding emacs lisp archives, the roles they fulfill, address identified discoverability issues, add infrastructure to encourage/support underlying philosophy etc.