What could possibly go wrong?

Even though I'm taking a keep-it-simple approach to this project, there still remains many variables that are well beyond my control.  These could lead to anything from a small error causing partial data loss, to a catastrophic failure resulting in an unrecoverable payload.

• GPS CoCom Limits:  This is potentially one of the biggest show-stoppers.  The Wikipedia article describes CoCom limits as"a limit placed to GPS tracking devices that should disable tracking when the device realizes itself to be moving faster than 1,000 knots (1,900 km/h; 1,200 mph) at an altitude higher than 60,000 feet (18,000 m)."
  
  The article then goes on to describe the way in which devices enforce these limits:  "Some manufacturers apply this limit when both speed and altitude limits are reached, while other manufacturers disable tracking when only a single limit is reached. In the latter case, this causes some devices to refuse to operate in very high altitude balloons."
  
  Somewhere, in the radio software for the handset, is either an 'and' or 'or' operator, and until the device is taken above 60,000 feet, I've no way of knowing how it will behave when this condition is met.
• Extreme Cold Temperatures:  Electronics and batteries do not  like cold temperatures.  Living in Australia, the coldest temperatures I'm used to seeing are usually on the warmer side of 0°, usually in the low single-figures.  However, at elevation, the temperature very quickly drops into the negatives, and at 100,000 feet, we can expect to see temperatures as low as -60°C - at which there's no chance of anything remaining operative - even the best-rated Li-on batteries are only rated to -40°C.  There's plenty of ways to keep the payload warm, however I'm only able to test to temperatures as low as my kitchen freezer has to offer.
• No Cell Coverage:  Prior to the return of the payload to earth, there'll only be an approximation of the expected landing site.  The trajectory can vary greatly with as little as an hours difference in launch time -  if it appears that the payload will find itself even close to an area void of cell reception, the launch will need to be postponed.  While there are a handful of balloon trajectory forecast sites, there's no guarantee of accuracy - so consideration needs to be given to the fact that the payload could potentially find itself 100 km+ away from the expected landing site.  With cell reception being the only means of contact upon landing, we need to maximise the chance of it remaining within a cell coverage area.
• Landing in Water:  If the balloon bursts prematurely or is blown off-course unexpectedly, there is the risk of a water landing.  Depending on what sort of body it lands in (lake, river, bay or ocean) there still may be a chance of recovery - so both buoyancy and waterproofing of the payload need to be considered.
• Script Failure:  Whilst extensive testing of the tracking and telemetry script will take place, there still exists a risk that the script, SL4A or device itself could crash, permanently severing communications with the payload.  Subsequently, I will need to consider implementing some form of redundancy should such a condition develop.

As testing progresses, I'll devise, implement and test potential mitigation strategies for each of these, and report back om my findings.