The pin value has changed to 1 with last event 1 after these contacts: 20 -25 40 -50 75
The tmr.now() glitch is less in SDK 1.4 AFAIK, and all this does is to introduce a very occasional perverse time offset in the logged open/close events. The point is that this type of logging will allow you to set a sensible dwell time for your actual relay. It can be commented out in production once the relay has been calibrated.
IMO, the 50µS delay is far too short for a mechanical device . You could comment it out and it will make little difference. What is adding a backoff delay is the print statement between the cb entry and the new trigger statement. (How long does it take to print 13 chars at 9600 baud?). I can't remember if this is synchronous or done by the UART driver asynchronously, but I do know that UART output does block possibly after a buffer element and doing too much can trip the software watchdog.
In general we always need to be aware of the bastardised version of the Heisenberg Uncertainty Principle: the observation always effects the experiment. (This isn't really anything to do with quantum physics hence bastard). But if you add UART-based logging to a time-critical process, then you will change the timing of what you are trying to instrument. Appending to an array will typically take a lot less time than the mechanical up/down of a bouncing relay and so give you a valid read-out.
Try my example and let us know what is being logged.