Yes. I have. When I looked at the device in the devices and simulators window it had a helpful yellow banner asking me to do that. I did it before all the things I tried above. (I did double-check though. Thank you for the suggestion) I also used the information in the tech note to look at the content of the provisioning profiles and I double-checked that the device showed up in the list. One thought I had was all the App ID's I've been using are wildcard IDs. I thought I might try using an explicit ID. I also need to try another device but I've been out-of-town and haven't had the opportunity yet.

I have disconnected and reconnected the device many times. I got back home and, unfortunately, I get the same results if I try to use an iPad (10.5 inch iPad Pro MPME2LL/A) so it maybe its something local to my setup. I tried uninstalling Xcode and reinstalling it and that didn't change anything. It's not just that Xcode thinks it can't install the profiles. If I email them myself on the devices and try to install them, that fails too. So the profiles are generated in a way that my devices don't like them. Is there a (publicly accessible) way to collect more information about why a profile was rejected other than just that it was rejected? (I will re-read the tech note so if the answer is in there consider that prior sentence to be rhetorical :-D)

You are kind to have shared your expertise. I will continue to chase the issue down. Thank you!

I eventually figured out what was happening. After re-reading the provisioning profile tech note, my eye caught on the paragraph which says that previously the user would install a provisioning profile accessible through the Settings on the phone, but modern iOS applications should have their provisioning profiles inside the app bundle in a file called "embedded.mobileprovision". In iOS 16.1, in the settings, I see provisioning profiles for things like Apple's beta software, but haven't gotten iOS 16.1 to install a new application profile. Perhaps that functionality has been removed? YMMV. At any rate, being thoroughly modern (ha!) my application, when built, should contain an "embedded.mobileprovision" file. But upon digging in the DerivedData folder and looking in the app package - it didn't. Odd. I looked at the build transcript and clearly saw a step that was supposed to put that file into the bundle. So then I looked at our build phases. To make a long story even longer, our application has a history that includes Ionic/Angular and Cordova. There was a script that copies the Ionic/Angular html files into the app bundle. I speculate that you use the Cordova build process then it will build the application using Xcode, then delete the signing that Xcode has done, copy the www folder into the bundle, then re-sign the result. Since we don't use the whole Cordova build process, the script was copying in the www files, then deleting the code signing, including the embedded.mobileprovision file... but need replacing it. I deleted the Cordova script, used a Copy Files build phase to get the HTML into the bundle, and let Xcode code sign the application.

Nevermind. Apparently I had one of my destinations wrong somehow and missed the notification that the destination was not recognized. After vigorously quadruple checking the destinations, cleaning my build folders, and building things again, the xcframework builds as expected without an error message. I suspect I had a typo in one of my destinations that was causing xcodebuild to select my local Mac as the destination and I missed the error message in output telling me I had a problem.

I managed to solve my issue by implementing a custom protocol framer as shown in the 2019 WWDC presentation Advances in Networking, Part 2 https://developer.apple.com/videos/play/wwdc2019/713?time=779 But I am curious why simply doing two receive calls in a row didn't work.