Yep. That is strange problem. Not one I can reproduce. I can only suggest a work around and see if that helps...
Instead of having assertions on the api invoke test step, maybe have the assertions in a groovy test step. Is the issue only related to assertions in one api invoke test step for one test case or assertions in any api test step in all test cases?
I prefer assertions in a groovy test step so they are not buried deep in the api invoke test step that I have to crack open each assertion to see what it is evaluating. I like to see all the assertions in code at one time.
This issue does not seem to be wide spread (at least others are not reporting it) so that leads me to believe something is specific to your situation. Is it a big project or one that has been modified a lot by different people with different versions of ReadyAPI? Maybe save it back to a monolithic xml project and then back to a composite project to see if it heals. I don't have an answer.
Above you wrote "I'm thinking of using another software." That seem less desirable (very expensive considering you have a large project with lots of time and effort put into it to just abandon) than trying to fix this.
Above you wrote "I can't change everything to use assertions in groovy instead of the assertions features". Can you change just one test case to use groovy asserts where you are having this issue? You don't have to change all the assertions to groovy in the project at once. Try just the one test case and see if it works. I don't know how many assertions you have for that test case that has the issue, but converting over to groovy for it shouldn't take more than ten minutes for every 20 assertions. After you do it once, every other one is a lot faster.
Above you wrote "I can't also switch from composite project to normal project.". I asked if you could change from composite to normal (save as normal) and then back to composite. It does not have to remain as a normal monolithic xml file project. I have done that work flow process in the past and it healed the composite project for me by aligning all the xml pointers that may have become corrupted. Saving from composite to normal and then back to composite is just a few mouse clicks. What is the reason that you can't do that?
Finally, if you think it is a bug, you can report the issue formally to the ReadyAPI Support team - you can do this here: