How to change the semantic version number by reversing the last major change

I am trying to plan a system that validates the compatibility of different components by comparing their semantic version number, especially the main version number (since it indicates API changes and compatibility with previous versions). I found the following scenario where I couldn't find an exact answer:

Let's say the code is in the version 2.3.5 and I add a new major API change, therefore, I update the version to 3.0.0. However, a few days after the launch, I find that this change does not adapt to the needs of the users, and I reverse this change so that everything that is compatible with the versions 2.x.x it will be compatible again (note that I am not doing a reversion of the version control, but instead return the previous version of the code in a regular confirmation). Now I can't understand if the new version should be 4.0.0 because again I made a major change in the API and the numbers should always be increased, or, because it will be compatible with previous versions again, use 2.4.0.

I see advantages and problems with both solutions. Are there basic rules or best practices for such cases?