One thing to point out is that every time you hit the "Send to Cube" button, this triggers a process in which the selected script is copied to our server, then compiled over the air and then sent back to your cube over the air. Depending on the script size, network conditions, etc, this process can be slow or sometimes appear to have 'stalled' (e.g., photon's LED is solid magenta or off for more than 2 seconds).
By looking at the most recent build logs it was noticed that the scripts you've attempted to send were built with very short intervals between each other. For example, between flashing Spark Pixels for the first time and then proceeding to flash Washing Machine, you waited less than a minute. Subsequently, you tried to flash Spark Pixels 3 times in a row within a 2 minute interval. Spark Pixels is a rather large piece of code. It will certainly not have been finished flashing in just a few seconds. That's just the way it is. Just reminding everyone that the button animation is provided as a rough reference, it doesn't really stay 'flashing magenta' for the whole measure it takes to flash the code; that is provided as a rough user feedback but the flashing times are estimated and not measured. Only the "compiling" animation is consistent with the compile time because in this case, we can get feedback from Particle. Then we start "flashing magenta" for a fixed period of time. So the actual over the air flashing has to be monitored from the photon's LED and not the button animation.
With the above considerations, the idea here is that in order to get the code flashed right, some patience is required. Try to wait until the photon LED gets back at breating cyan, and then, if the viz animation hasn't changed at all in the cube (as a reference, each time the code is successfully refreshed the cube resets itself), try one more time. This simple change in attitude will increase your chances of success.