I am in the middle of writing a section related to this. It's dealing with how regular dnf looks at these packages different than koji's buildroot looks at the package.
When a package is built in epel-next, and then it is later built in regular epel, koji continues to use the epel-next package in the buildroot, whether there is a newer package in epel or not. Thus, it is highly recommended that package owners untag their package from epel-next after they have built the corresponding package in epel.

So, here comes the question, and I'm not being sarcastic with this question, I really want to know so I can put it into my section.
What benefit does it bring to bump the release, if you are going to untag the epel-next package right after you build the epel package?

User experience for CentOS Stream users. If packages are built with lower release number in epel than epel-next and package is untagged from epel-next, that will cause CentOS Stream uses not to get package update causing them to have extra packages installed in their system causing confusion. That is why new builds on epel should have higher release than previous build on next.

Also process for maintainres is to just build on epel-next if there is incompatible update on centos stream. That will cause issue because there is no release bump in this case, so maintainer would hit siutiation where he try to build a package on next with a same release which was already built on next.

Also process for maintainres is to just build on epel-next if there is incompatible update on centos stream. That will cause issue because there is no release bump in this case, so maintainer would hit siutiation where he try to build a package on next with a same release which was already built on next.

I think you are going to extremes here.
If a package maintainer needs to rebuild a package due to CentOS Stream bumping a library, or something like that, they should know that they need to bump the release. And if they don't, koji will tell them.
It isn't that big of a deal.

But since you bring up maintainers, that is a real reason why we don't require the bumps when going from epel-next to epel.
Let me walk you through their process. (Note, there are exceptions to this, but 99% right now are done this way)
1 - Work get's done in Fedora, and most of the bugs are cleaned up there, often in rawhide and/or stable branch.
2 - They do a git sync to from f38 to the epel9-next git repo. They build their package on epel9-next.
3 - Any epel9-bugs get fixed and pushed back to rawhide/fedora.
4 - Repeat steps 2 and 3 until things feel stable.
5 - When the time is right (often at release, but can be sooner) - git sync from epel9-next to epel9 and build packages.
6 - (recommended but not required) When package is in epel9 stable, untag from epel9-next.

Here is what you are recommending with this pull request:
Replace 5 with
5 - When the time is right (often at release, but can be sooner) - git sync from epel9-next to epel9, bump release and build packages.

Here is what you probably really meant:
Replace 5 with
5 - When the time is right (often at release, but can be sooner) - bump release then git sync from epel9-next to epel9 and build packages.

But in either case, you are changing step 2 to:
2 - They do a git sync to from f38 to the epel9-next git repo, where they have to manually resove git conflicts for 90% of their packages. They build their package on epel9-next.

I honestly don't know why git can't figure out a bump release diff, but it fails so so often, and yet not always.

In short, the way we currently have it is FOR the maintainers, to save them work and confusion. We realize it can be confusing, which is why for epel10 we won't have -next. But epel8-next and epel9-next solved the CentOS Stream problem with the resources we had at the time.

Note - I want to address the first part of your comments, but I took so long on that one that I need to put it off for a while to get other things done. I'm not ignoring it.