This one I've seen quite a lot, usually with digital task trackers (the much-hated Jira being one of them, which is quite surprising because Jira natively supports the "correct" way of carrying items over) — probably because the operation of copying is so cheap there. Whenever a team is not able to complete a story, they clone it to the next iteration. The original story becomes "part N" and gets closed and the clone is now "part N+1".
There's a number of possible reasons why this happens. The most obvious is probably the team's desire to reward themselves for performing work, otherwise, they are left with the feeling of unfairness. Another typical reason is cargo-cutting the golden rule of fitting a user story in a single sprint. I've seen both in my career. Instead of focusing on the root cause, a team simply makes up an artificial completed item.
Such a way of tracking work has numerous issues.
First of all, it never actually shows real progress. Whether a user story is done or not can only be evaluated with the ultimate objective criterion — is it live or not. In Scrum, you can strengthen (or weaken) this criterion by the means of Definition of Done. This aligns with one of the Agile principles: working software is the primary measure of progress . By cutting a user story into parts like shown in the example you are doing something as nonsensical as saying, "I've mowed half of the lawn, although I still don't know how big it is". How do you know then it's a half and not a quarter?
Second, such tracking removes the incentive of slicing user stories vertically into smaller pieces. There's no pressure to have a story that you can truly complete in one sprint because you have a 100% guarantee to have a completed item at the end of each and every sprint.
Then, if you use a digital tool for tracking, it messes up with your data. There's no easy way to calculate true lead time or true velocity when you keep adding entities for the same piece of work. The data on the items doesn't show true numbers and if you want true numbers, you need to aggregate them from multiple different sources.
And lastly, continuously cloning items simply wastes your time on unnecessary activities. I've seen teams wasting the entire sprint review on just creating new clones in TFS for the next sprint.