During testing of 220.127.116.11 I saw this a couple of times: The (virtual) machine was looking for updates in the background (which sucks one CPU at 100% on Win7) and additionally had just been brought back awake from a snapshot (so there was some load going on in the background).
During the install I got a warning about an access conflict to one of the jetty or procmon logs but waiting allowed one to continue and after install the start.jar in the jetty installation was missing.
Adding logging to the install is enough to disturb this and make it work but I suspect that the shibd_idp service hadn't complete stopped (as part of the shutdown) by the time that the upgrade started running and so we get some sort of weird behavior which allows start.jar to be deleted but not reinstalled.
This is the stanza that starts/stops the service
Note the Wait="no which is needed because a freshly installed IdP won't start (and there may be good reasons why an update won't) and we really don't want this to cause the install/update fail and to back off.
At some stage I need to try to replicate this and fix. The only way I can imagine doing it is to clone the standza but conditionalize the component on install/uninstall, then make the uninstall version wait (testing of course to ensure that the wait still works if the IdP isn't installed).