TL;DR: Yes, it is perfectly fine if a defect is re-classified.
I like to promote the zero defect policy. Meaning that your backlog should not contain any defects. Blockers and critical issues should be fixed asap. Other issues are often improvements and not really defects. We could discuss the wording and definitions, but deciding what is and what is not worth fixing is way more important.
I would add a fifth classification "Trivial" for defects that should never get priority, because they are to trivial to work on. Report them and close it. Make sure you communicate clearly and fair.
Now your example:
The issue is that customers can still place orders having zero items
i.e. zero total cost.
Are customers really going to do it? Does it block their normal flow? Is it business critical? I think the answer here is No.
Now I think it is part of an existing feature thus an improvement. It can be lived with, but some users might run into it by accident. The impact might be that someone needs to clean up the system manually. This might make me think this should be improved, but maybe it can wait until it really happens in the wild.
Keep in mind the goal is not to make perfect software. The less work you do the more value you can add to change the world. Long defect lists do not help with adding value to the software product.
- Keep your defect lists short.
- Triage if defects are improvements or features continuously.
- Try to maximize addition of value by limiting the work you execute