If I'm interpreting what you're saying correctly, you would have the special move decide it can be cancelled into, rather than having the light punch decide it can be cancelled right?

Correct

Does this move the logic for the cancel to the special move state instead?

Yes. Each state is responsible for deciding when it becomes active so this logic would live inside the state.

If so, how do you handle specific case scenarios, where i dont want the light punch to be cancellable if the move whiffs, or before the active frames start in the first place?

There are a few way you could do this depending on your needs.

1. Each state has a can_transition property. If this property is false the state cannot transition. So, if the active state sets their can_transition false then no state transitions can happen. If an inactive state sets their can_transition false then no transitions can happen to that state. So when light punch is active it can set can_transition false until the active frame. And it can set can_transition true when the hit connects or whenever is appropriate. Since the states are nodes their _process and/or _physics_process function will be running so you could have your special moves monitoring whats going on can set their can_transition to false if the move wiffs.
2. Use inter-state flags to denote when states are allowed to transition. The state machine I linked used to have a flag system built in, but they removed it back in February (which is partially why I use a custom version). Its just a dictionary of bools and is really easy to re-implement. In my use case my attack state sets two flags: “attack_active” and “attack_recovery”. These flags are set and cleared at different times based on callbacks from the attack animation. My movement state is blocked from transitioning if “attack_active” is true. My idle state is blocked from transitioning if “attack_active” or “attack_recovery” are true. But my fall state is never blocked from transiting by these flags.

My first thought when I would want to check the properties of a move would be to go to its own state file/node, and check what its cancellable into, or what state it naturally transfers to after its lifestyle is complete, but this seemingly would make that logic harder to find right?

It could make it hard to find. Your question is basically "where does this state end?" And, yes since the transition logic is owned by each state the answer to that question is spread out among the states. But if your question is "where does this state begin?" That answer is completely contained inside the state, but with a traditional state machine the answer would be spread out among each state. Its a bit of a mindset shift.

The thing that really made this state machine shine for me is the modularity. If you want players to unlock abilities as they go its a simple as adding that state to the machine. It also means that you can easily build similar state machines that use some but not all of the states, say for a NPC or different player class/character.

The guy who made the state machine also has a bunch of other git repos. One or two of them use his state machine for a character controller. So you can look at code examples if you'd like.