I don't think I understand exactly either. I understand that we are looking to see that state change initially and comparing to that time in terms of millis() for debouncing purposes, but I gather there is more to the button pressing state change that you mean?
I guess it would make more sense if I knew which code was which, in terms of what you're referring to... I could definitely work backwards from there and make sense of it in this specific case.
Your code is oriented around checking for the state change cycle AND THEN outputting a button signal. And that in this case, you are suggesting the reason why my code (with use of that library) was skipping was that the debounce protocol was effectively not detecting the state change cycle of the button, just that the button is pressed.... and since the button was still bouncing, it would come back to check the state of the button, to see it is different than reference, so it continually sends out a signal?
I would have maybe more intuitively seen that, however I did test this with 200ms of debounce and the results were the same. So that's where I'm confused. I suppose the issue is that I don't understand the library I used. But again, 200ms is high for any button.
However I do appreciate you bringing that point back up, because after some thought I think I understood your point..
To me, personally, the literal explanation of button being pressed vs is pressed was a bit confusing. And I find the idea of calling it a button state change cycle a bit more precise. But that is just my honest reflection