Or “Do we split Stories that are not Done at the end of an Iteration?

We refer to the Agile principle “Working software is the primary measure of progress” to decide what makes sense. In this context, this means that at the end of an Iteration a story can only be in one of two states: it is either “done” per your Definition of Done, or it isn't. If it isn't done then it goes into the next Iteration.

The easiest approach to support is simply to put the incomplete Story into the next Iteration (no re-estimating, no re-writing, etc.)

While this approach doesn't feel like it should work, provided the number of times this happens is relatively small, tools you might use to understand how much you can take on (average velocity over time), should not be significantly impacted by this practice.

Context matters, and so there might be other considerations. For example:

• You might have delivered some level of value with the work you completed, just not all of it. Perhaps out of 3 acceptance criteria, you have delivered 2 to your Definition of Done. In this instance you might consider splitting the story so that the story in the current sprint has the first 2 acceptance criteria, while the third acceptance criteria goes into a new Story that will be considered for the next Iteration.
• Your ART or other organization might choose to have different rules in order to maintain reporting consistency.

One thing to remember is that this situation should only arise infrequently. If you are constantly carrying over multiple Stories from one Iteration to the next, then your Stakeholders will be (rightly) concerned about you ability to make and meet commitments. This situation should be the subject of your Retrospective - is the root cause related to the estimation process, to the use of historical velocity data, or something else?