LLDB fails to load Clang explicit modules due to class_ro_t pointer authentication mismatch when using Xcode 13.3

Debugging with explicit modules has started failing on XCode 13.3 and newer. The exact error I'm seeing is:

warning: (x86_64) /Users/ivhernandez13/dev/ClassROTPointerAuth/.build/x86_64-apple-macosx/debug/ClassROTPointerAuth unable to load swift module "ClassROTPointerAuth" (failed to get module "ClassROTPointerAuth" from AST context:
error: class_ro_t pointer authentication was disabled in PCH file but is currently enabled
error: module file .build/x86_64-apple-macosx/debug/ModuleCache/Printer-20306afde488b50a0d5da96c5d1db469db2b1c0bea812fcbedeed3407295ab41.pcm cannot be loaded due to a configuration mismatch with the current compilation

I tried to trace down where class_ro_t pointer authentication was being enabled in LLDB and found it is controlled by a new clang flag -fptrauth-objc-class-ro only available on clang included with Xcode 13.3 and newer. I can't find it in the open source clang so can't determine where it is being enabled.

You can find the log file I get from enabling the lldb types log here. ClassROTPointerAuth is the sample SwiftPM macOS project with explicit modules that I can repro the issue with. In the real (closed source) project(s) I'm seeing this with, failing to load explicit modules leads to LLDB falling back to the SwiftDWARFImporterDelegate for importing debug info where it fails at some point and LLDB crashes. Oddly enough the class_ro_t pointer authentication mismatch only occurs occasionally. When the mismatch doesn't occur LLDB loads the explicit modules just fine and expression evaluation works.

The current workaround I'm using is to explicitly disable class_ro_t pointer authentication in LLDB's clang options with settings set -- target.swift-extra-clang-flags -fno-ptrauth-objc-class-ro which seems to work in preventing the mismatch and succeed in using explicit modules. Is the enablement of this new flag in LLDB intentional and if so what would the recommended way to disable this when using explicit modules be?