Xilinx Zynq - harder to implement than one would hope

So I get a new Zynq ZC702 development board, and I'm tasked with making it work. I got the new ISE 14.2 development tools from Xilinx. Here are some things you might want to know if you encounter the same board.

The FPGA logic is the PL (Programming Logic), and the A9 subsystem is the PS (Processor System). Don't attempt to use Impact to burn anything! The burning is all done through an application called zynq_flash.exe.

Do not use Project Navigator to build this FPGA bitstream! Even if you wanted to, which I did, you will find that ngdbuild crashes most of the time (when using the embedded A9) in this flow. Use PlanAhead. It is the new recommended flow from Xilinx. Its also a surprisingly good flow.

The flow I'm using is:
Create a project in XPS. Set up everything that you need for interfacing to the PL there.
Export the project for the SDK, it's an option in XPS. Don't generate the bitstream. Don't launch the SDK.
Create a new project in PlanAhead. Import the .xmp project that you created in XPS. Right click on the embedded processor to create a stub file. Add your source files, and build the rest of the project there.
Generate a bitstream.
Open SDK. Create a new hardware platform specification. Browse for the .XML file under the XPS project in the SDK export folder. Choose the bitstream that was built by PlanAhead. If you have a .bmm file, then use it.
Create a new BSP based on this platform.
Create a new C project and choose Zynq FSBL. You need the FSBL (First Stage Bootloader) to burn the FPGA. It is also needed by the A9 to boot up. Select the platform that you created for the FSBL.
Create a project for your application based on the platform you created.

To burn, right click on the application, and choose to create image. It will automatically add the FSBL, bitstream, and application. To burn the new .mcs file, use the Xilinx tools menu, and burn flash. This is using the zynq_flah applicaion.

Some caveats, I have seen zynq_flash claim to burn even when it doesn't. If the erase step doesn't take at least a few seconds (more like 30+), then it's not working. I have never seen the verify option work at all. If it isn't burning, then turn off the board for a few minutes, and try again.

That's about it.

Libero SOC and IO constraints

A rule that I have always kept to is : Keep design source files as text! A  while back I had the misfortune of using ATEasy. Back then all ATEasy projects were binary, and the sources were stored in the project. This made it very hard to compare versions or to store the sources in revision control. This was bad back then. Even then, ATEasy became aware of the problem and added an option to store project files as text.
Getting back to Microsemi / Actel... The newest version of the tool no longer allows out to use a PDC file to store IO constraints. You must maintain the constraints from within Designer. This is unpleasant to say the least. The constraints are held in the Designer project file. The project file is not only binary, but it is updated on every run.
You can of course import a PDC file, but don't try and change the IOs around without first opening the tool to unassign all IOs from the Designer database. Otherwise you'll get errors about conflicting IO assignments.
Please fix this!