From a formal Scrum perspective, the format and contents of a Product Backlog Item such as a user story is undefined. The Product Owner is solely accountable for its contents, and must ensure that "the Product Backlog is visible, transparent, and clear to all." Scrum doesn't formally specify any other artifacts, so creating a special status outside of the Product Backlog is going to be either idiosyncratic to your project or a known anti-pattern.
Rather than track this sort of dead weight, it's often better to communicate with stakeholders about the story. Either alternatives can be found, or the story is treated as an ephemeral artifact that will be removed from the project's collective consciousness, to be revisited in the future if needed.
Agility is about collaboration and communication, not spelunking through long-buried artifacts. If you're creating an artifact just to archive it, don't. There are more agile approaches built around people and interactions.
Perennial Low-Priority Stories: An Anti-Pattern
Within the Scrum framework, a Product Owner could keep "won't do" items forever at the bottom of the Product Backlog, but this is usually a bad idea that's covering for some other process problem.
First of all, consider the point of tracking won't-do items in the first place. Teams or stakeholders generally implement something like this either as an accountability artifact (e.g. "Bob brought this up; we looked at it rather than ignoring Bob; it's not feasible.") that nobody ever dredges up unless people are pointing fingers, or as a (largely ineffective) mechanism to prevent duplicates entering the workflow.
In a large or long-running project, the Product Backlog continuously grows and evolves. Over time, more and more won't-do items will get added to the tail of your Product Backlog, to be either totally ignored or as a growing form of technical debt that must be paid by constantly revisting old items.
Keeping won't-do stories on the Product Backlog also fails as a duplicate-prevention control, because free-form text comparisons are hard to automate, and user stories can vary just enough that two almost-identical stories are rarely exact duplicates. This also creates technical debt, because now the Product Owner has to compare each incoming story to some legacy story to see if it was already addressed. Even if this wasn't cumbersome, it's also pointless because the business context around why a duplicate or similar story is being introduced now is more important than the fact that something was addressed at some point in the past.
Additionally, the reasons something was impractical in the past may no longer be so. Keeping legacy decisions around serves very little purpose other than CYA. The real question for the Product Owner is whether the requirements have changed, and whether the team can provide a solution for the current need.
Other related solutions simply create zombie stories or additional reports and artifacts that create very little value, but often involve additional process overhead. The basic advice here is "just don't."
Solve for X with Communication and Collaboration
Another reason people want to keep zombie or discarded stories around is because they have an X/Y problem. For whatever reason, communication or collaboration with stakeholders or customers is poor, and rather than fix the underlying process issue teams try to mask them through artifacts like rejected requirements. Don't do that either.
The Agile Manifesto's four core values are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Zombie stories or rejected requirements don't really reflect any of the values on the left. There are more agile approaches to the need than keeping legacy artifacts around forever, creating drag.
Find the X in an X/Y Problem
First of all, consider the need. If Bob in accounting keeps requesting Feature X, there's probably some business need or workflow issue that Bob thinks will be solved by implementing this feature. As long as this underlying need remains unfulfilled, this backlog item or ones just like it will keep cropping up as they should!
Rather than "rejecting" the story as infeasible, the Scrum Team should collaborate with Bob to figure out the underlying problem that the feature is supposed to address. Maybe there's an alternative solution that the team can implement, or perhaps there's something that needs to change about the organizational process or workflow. In any case, rejecting a request or trying to block future requests of a certain type is the opposite of collaboration or embracing change.
Involve Stakeholders; Don't Status Them
Secondly, marking Product Backlog Items and keeping them around is a proxy (and a poor one at that) for effective communications. Rather than talking to Bob, or collaborating on a solution, the Scrum Team is attempting to rebuff or block Bob in a non-personal way by labeling or categorizing the backlog item. This is a way of limiting communication rather than opening up a dialogue, and is therefore non-agile.
Bob deserves some direct feedback. This may be from the Product Owner or from the Development Team, depending on the disposition of the item, but in any case someone should talk to Bob. Bob is an individual, and should be treated as such. If he's a stakeholder, then he's part of the reason the Scrum Team has formed, and should therefore have visibility into the team's capabilities, priorities, and resources. If nothing else, knowing that what he's asking for is infeasible and why could help Bob make better use of the product or find an alternative solution on his own.
Finally, zombie stories are an artifact that assumes the project or its business context will never change. Teams gain and lose capabilities, products evolve, and the business environment is rarely static. A story that was infeasible six months ago might be practical now. A story that was too resource-intensive before might have a new technical solution. Something that could be dismissed as impractical in the past might be sufficiently business-critical today that finding a solution or throwing more resources at the problem are essential to the business.
By keeping the Scrum process free of legacy decisions, you free up the team to address backlog items within the current context. Why does it matter if someone brought up this story last year? It's important now! Why does it matter if it couldn't be done before? It might be possible now! In all such cases, the important thing is to address the current need in the current context, and to prioritize it against current project resources. Anything else is not embracing change.