I think it would make sense to support C++ as well, as it's now supported in Swift 5.9 . The implementation of the proposal needs to ensure that the .interoperabilityMode(Cxx) setting is respected by the Swift code in mixed-language target, and everything else should fall into place I think.
For this specific statement
Additionally, when present, each non-Objective-C/C header (e.g. a C++ header) is excluded from the module. This avoids build errors that arise when exposing, for example, a C++ header to Swift
I think mixed-language targets should not exclude C++ headers from the module, even when C++ interoperability is not enabled, as that could be an obstacle in the future that makes it more difficult for us to make C++ interoperability a feature that's on by default or doesn't not require a flag/setting to turn on. Users who don't use interoperability would need to then guard their C++ in headers in #ifdef cplusplus blocks. Also relying on an extension of the header is not necessarily 100% accurate , as people commonly place C++ code into .h files as well.
This module map defines an umbrella directory at the target’s path, exposing all headers for the target. When used to build the target’s Swift sources, the target’s Swift sources can use all types defined in the target’s headers, as opposed to only types declared in the target’s public headers.
It might also be good to figure out some way to allow users to exclude headers from the module that's brought into Swift, as some headers might not be modularizable, for instance .inc files that are then always textually included into other headers.