This is the section from the CLLocationManager documentation describing the app behavior with startMonitoringSignificantLocationChanges:
If you start this service and your application is subsequently terminated, the system automatically relaunches the application into the background if a new event arrives. In such a case, the options dictionary passed to the application:didFinishLaunchingWithOptions: method of your application delegate contains the key UIApplicationLaunchOptionsLocationKey to indicate that your application was launched because of a location event. Upon relaunch, you must still configure a location manager object and call this method to continue receiving location events. When you restart location services, the current event is delivered to your delegate immediately. In addition, the location property of your location manager object is populated with the most recent location object even before you start location services.
So my understanding is that if your app terminates (and I assume if you don't call stopMonitoringSignificantLocationChanges from applicationWillTerminate) you will get woken up with a UIApplicationLaunchOptionsLocationKey parameter to application:didFinishLaunchingWithOptions. At that point you create your CLLocationManager, call startMonitoringSignificantLocationChanges and do your background location processing for a limited time. So I am fine with this bit.
The previous paragraph only talks about what happens when the app is terminated, it doesn't suggest what you do when the application is suspended. The documentation for didFinishLaunchingWithOptions says:
The application tracks location updates in the background, was purged, and has now been relaunched. In this case, the dictionary contains a key indicating that the application was relaunched because of a new location event.
Suggesting that you will only receive this call when your app is launched (because of a location change) after you have been terminated.
However the paragraph on the Significant Change Service in the Location Awareness Programming Guide has the following to say:
If you leave this service running and your application is subsequently suspended or terminated, the service automatically wakes up your application when new location data arrives. At wake-up time, your application is put into the background and given a small amount of time to process the location data. Because your application is in the background, it should do minimal work and avoid any tasks (such as querying the network) that might prevent it from returning before the allocated time expires. If it does not, your application may be terminated.
This suggests you are woken up with location data if your app has been suspended, but fails to mention how you are woken up:
In the process of writing this up, I think I may have just answered my own question, but it would be great to have my understanding of this confirmed by someone more knowledgeable.
Since I asked this question, I have done a fair bit of testing (mostly on the train between home and work) and have confirmed that the behaviour for suspended apps is as I suspected at the end of the question.
That is, your suspended app is woken up, you don't receive any callbacks on your app delegate, instead you receive your location updates through your existing CLLocationManagerDelegate. You can detect that you are running in the background by checking the applicationState, and do limited work for the case where you are woken from a suspended state to do location processing.
[UIApplication sharedApplication].applicationState == UIApplicationStateBackground
I came to this conclusion with a location test harness that you are welcome to download and try out. It is a pretty simple app that allows you to turn on significant change and GPS change APIs through the UI and log all the responses that you get back.
N.B. Point six in the previous answer is not correct. Freeze dried suspended apps do receive CLLocationManagerDelegate callbacks when they are woken up from a suspended state.