I'm not sure that enforcing uniqueness of RPM Summary tags is a good idea. There's even cases in which it's not really possible, like compatibility packages that supply different versions of the same package, where the Summary would obviously be the same in both ones.

I wonder, since %name is already the unique identifier for RPM packages, why would the Summary (or even %description) need to be unique too?

To be accurate in regards to semantic, that is presently because '%{name}' had been chosen from the beginning of the Fedora project as the only package unique identifier, that no search queries since then could reliably be made against any other tags.

As a package name is not meant to be self explicit, then to encompass its associated summary and description, it turns out that a package with summary "The Linux kernel" won't be found and for a reason indeed since that it is not unique and then allows the existence of duplicates. Here wew are: that package to be discovered won't be, which obsoletes the validity a search query. A non-sense as expected.

As noticeable from 'dnf rq --querytags', the lack of a dedicated tag versatile enough to cover all types of packages: would then be needed, so that compatibility packages could be filtered not to pass through in search queries.

E.g. of types of packages:
- conventional package – Contains files;
- compatibility package – Contains files, supplies a different version of a conventional package. Therefore those packages and the conventional package they are versions of share a common summary and description.
- meta-package – Does not contain files, therefore its size is null. fail2ban is such one.
- (...)

I'm afraid I don't see the benefit in this, or how the proposed rule even helps you get closer to what you seem to desire. You could embed a timestamp or some random non-descriptive data into the summary and description. Even the package name itself would suffice (though that's frowned upon in the summary). So yes, it would be unique, but that doesn't actually have any useful result.

The smart thing for the example you have given is, instead of trying to make new bureaucracy, just asking the kernel folks if they can add some more useful descriptive text for the various subpackages where what is there is not sufficient to eliminate confusion.

Hold on to it, a fault is only committed if it is given the opportunity to be committed. So leave the team responsible for kernel development in peace or even any other; it cannot not be at the root of the fault that you attribute to them. Could not you even see that? What a day? Indeed.

The golden rule: Allow the creation of conventional packages with duplicate summary and description, be they random non-descriptive data or not. Then afterwards hasten to interfere and ensure that these packets receive unique summary and description and non-random non-descriptive data.

That is common bureaucracy in action. I did not think i would have to learn how it may be revealed to a stranger. Let's close then, It's not my job to educate the people after all.