Looks like it's working now.

@App Store Connect Engineer Thanks! Confirmed working now.

I submitted feedback to Apple about this issue. They asked me for a sysdiagnose from the watch and the phone. I provided that and they said the sysdiagnose from the watch appeared to be 'incomplete' and should be a few hundred megabytes (the one I submitted was ~50 megabytes). They said I should try again and if the resulting sysdiagnose still wasn't the expected size, I should try taking the sysdiagnose using a command line and using the “-L” parameter. I wasn't able to figure out how to execute the sysdiagnose from the command line on the Mac to gather data from the watch but I followed the directions specified in https://download.developer.apple.com/iOS/watchOS_Logs/sysdiagnose_Logging_Instructions.pdf and resubmitted another sysdiagnose. A couple of days later, the feedback ticket resolution was updated to "Investigation complete - Works as currently designed" with no other information. Meanwhile, I continue to experience this issue.

I heard back from DTS on this issue and they told me that what I'm seeing is due to "undefined behavior" after requesting 'always' authorization for location data. They said that since none of the monitoring APIs in Core Location (like the significant change location service, region monitoring, etc.) that actually require 'always' authorization are supported on watchOS, the authorization prompt that appears after I request 'always' authorization is "mostly a place holder and ends up causing the undefined behavior" that I observed. They further stated that if my goal is simply to continue receiving location updates when the app is in the background, that 'when in use' authorization is sufficient for that purpose as long as the app still declares the background location update mode and the location manager instance has its .allowsBackgroundLocationUpdates property set to true. However, the call to .startUpdatingLocation() must occur while the app is in the foreground. Finally, they added that it is not possible to stop and restart location updates while an app is in the background on watchOS. It's still not clear to me why this behavior differs when the code is run on the "Apple Watch Ultra (49 mm)" simulator vs the "Apple Watch Ultra (49 mm) via iPhone 14 Pro Max" simulator or on an actual Apple Watch Ultra. But regardless, it sounds like developers should not be requesting 'always' authorization for location data on watchOS and, that being the case, Apple should probably update their docs accordingly.

I've opened a DTS ticket to get some clarification on this but while I wait to hear from them, I've done some additional investigation and have observed something interesting. Xcode has a watchOS Simulator titled "Apple Watch Ultra (49 mm)". When I deploy the code to this simulator, it behaves as I would expect it to. That is to say, after granting "always" authorization in the second prompt, I get one more callback to locationManagerDidChangeAuthorization(_:) which indicates manager.authorizationStatus == .authorizedAlways and then the authorization prompts cease. I am now able to start location updates and receive them with the app in both the foreground as well as the background. Opening the Settings app on the watch simulator and navigating to Privacy & Security → Location Services, I see the app listed and it indicates that it has "Always" access to location data. Tapping that row shows that the settings ("Never", "Ask or When I Share", "While Using the App" and "Always") are still disabled but again, "Always" is selected and the app appears to function properly. There is another simulator in Xcode (listed under iOS Simulators) titled "Apple Watch Ultra (49 mm) via iPhone 14 Pro Max". If I deploy the code to that simulator, I experience the behavior I described above in my original post. This is the same behavior I encounter if I deploy the code to a real Apple Watch Ultra that's paired with my iPhone. So now I'm wondering if, despite being an independent watchOS app, this behavior is somehow related to the watch trying to use location data from the paired iPhone? As I said above, the location authorization prompts only appear on the watch (I've tried keeping the iPhone nearby and unlocked when running the watch app but still don't see any location authorization prompts on the phone). Could the prompts on the watch (after the first series of prompts, I mean), actually be asking for location authorization on the paired iPhone? If that's the case, I guess I'm still not sure why my selection(s) in the authorization prompts aren't being applied to the phone but at least it would give me something to go on.

For what it's worth, developer technical support told me that what we were trying to achieve is not currently possible in watchOS. They suggested filing feedback and requesting this capability which I have done.

I've spent the past week trying to find a good solution to this problem but have been unable to do so. Unless I'm just missing something, it doesn't seem like there's a good way to accomplish the same thing on watchOS that we've been able to do on iOS without having to keep location updates turned on all the time. Can anyone from Apple confirm that for me?