This document is meant to be read after reading the explanation of 1.5 piston mechanics. I also recommend watching Myren Eario's video on block events.
Before the game tries to process a block event, it will check that the block ID of the block in the saved position matches the saved block ID. This will prevent block transmutation. However, the game does not check for orientation for example.
In 1.8 this allows for piston bedrock breaking as discovered by Myren Eario (see his video on headless piston technology). This is unfortunately not possible in 1.5 due to the specifics of how pistons work in this version. However, we can do some other interesting things.
Our goal is to schedule an extension on one piston, replace it with another, and then have the game process the block event on the new piston. Because the block event will save the original piston's orientation, the substitute piston is going to get rotated.
We are going to start from the following sequence of block events where #1 is the original piston and later the substite piston, and #2 is the piston pushing in the substitute piston:
#2 process extension
#2 process retraction
#1 process extension
While we are pushing in the substitute piston, we will also be pushing away the original one; this is the purpose of the #2 extension. The #2 retraction is what facilites the block dropping of the substitute piston. This is what will place the piston there.
However, there is a problem. The #2 retraction can only be scheduled when the piston is extended. The problem with simply scheduling the #2 retraction and #1 extension after the #2 extension has been processed is that the original #1 piston will have been turned into a moving block by the #2 extension.
We could try to schedule the block event during the #2 extension by either chaining the update from a no-push mobility block destruction or by having the placement of a moving piston blocks destroy a detector rail (similar to TNT duplication). But remember that pistons will only set themselves to extended at the very end of the extension; that is after any opportunity for a block update.
One possible solution is to use a headless piston. This way the piston can be in the extended state before it even extends. It is possible to schedule an extension on a semi-retracted headless piston using the following sequence:
depower, schedule retraction (extended => retracted)
power, schedule extension
===
process retraction, cancel (retracted => extended)
process extension (extended => extended)
We can use this method to schedule the retraction before the extension is processed, solving our problem:
#2 depower, schedule retraction (extended => retracted)
#2 schedule BE for depower
#1 schedule BE for power
#2 power, schedule extension
===
#2 process retraction, cancel (retracted => extended)
#2 depower, schedule retraction (extended => retracted)
#1 power, schedule extension
#2 process extension (extended => extension)
TODO: I have this worked out in theory, but I have not wired and tested it yet.