Locking at 60 fps is certainly viable. From what I've seen, just as you've said, it appears fighting games typically describe timings in number of frames, even as most fighting games have transitioned to 3D (where it's rare to rely on discrete frames of animation). The drawback is that the game will slow down if the framerate dips below 60 fps.

If you want to, as you've put it, separate "logic" frame rate from "rendering" framerate, you can do your logic in FixedUpdate() instead of Update(). The physics system (which governs the rate of FixedUpdates) can be configured to whatever framerate you want to use, and won't be slowed down by rendering, although with enough of a load on the CPU, the FixedUpdate rate can fall behind its target, too.

Locking at 60 fps is certainly viable. From what I've seen, just as you've said, it appears fighting games typically describe timings in number of frames, even as most fighting games have transitioned to 3D (where it's rare to rely on discrete frames of animation). The drawback of doing this logic in Update() in Unity is that the game will slow down if the framerate dips below 60 fps.

If you want to, as you've put it, separate "logic" frame rate from "rendering" framerate, you can do your logic in FixedUpdate() instead of Update(). The physics system (which governs the rate of FixedUpdates) can be configured to whatever framerate you want to use, and won't be slowed down by rendering, although with enough of a load on the CPU, the FixedUpdate rate can fall behind its target, too.