Should marker 0 be a special-case?

I question the usefulness of having a special-case 'Power On' marker (or 'Savestate', if the movie is savestate-anchored) that can't be deleted or moved.

If it's always on frame 0 as the standard game start, then it's kind of redundant. I also can't recall any specific instance where it has any usefulness whatsoever; generally it's just something that takes up space and I ignore. One potential advantage I can imagine is clicking on the Power On marker in the sidebar list to seek to frame 0, but you can always scroll back up to frame 0, or retain the Power On marker while still having the option to delete it; it doesn't need to be indelible.

Current related bugs

Specifically, the current implementation for the 'Power On' marker has several active bugs, and seems to present a future maintenance burden disproportionate to the potential usefulness of retaining its special-case status:

• You can rename the marker by creating a new marker at frame 0
• If you delete frames from the beginning until another marker and have Bind Markers to Input on, two markers will occupy the same frame. This only occurs for the 'Power On' marker because other markers would have been deleted by merit of deleting the frames they occupy. (This occurred both before and after my changes to the delete frames logic).
• If you insert frames at frame 0, the Power On marker will be moved. This was introduced by my changes to the insert frames logic.

Resolving bugs, maintenance, and conclusion

I believe the current solution is to haphazardly check for frame 0 in certain situations where markers could affect Power On, but this is not very robust and requires updates every time a new method for modifying markers is created. A better solution might be to entirely remove the 'Power On' marker from the standard markers list at all, but just refer to it in the appropriate places (when displaying the sidebar list and the ). However, this would amount to 1-indexing our markers list somewhere in the code, which also seems inideal.

In particular, the second bug I presented in my above list is an interesting conceptual problem: what is the ideal resolution? Are we going to silently delete a marker when it overlaps with the Power On marker? Pop up a dialog box warning the user one of their markers could be deleted frames at frame 0? Get rid of marker binding entirely to avoid such a situation (I jest)? Sure, this is perhaps a niche case in practice, but I believe it's an illustrative concrete demonstration of why having a special-case marker complicates all of the marker handling code disproportionate to the benefits.

Start by tracing marker handling for the sidebar list, frame insertion and deletion, and Bind Markers to Input, with special attention to the frame-0 Power On marker. Decide and document the intended behavior for renaming, moving, deletion, and overlap at frame 0; done means the chosen design resolves the listed bugs without adding scattered special cases.