Thanks for pushing this forward @pschuh! I've been playing with this idea for the last few days without knowing there's anyone else driving it at this time.
My initial plan was to start with simple codegen tools that would be able to use ClangSwift to scan C++ declarations and generate C wrappers around that. These C wrappers could be imported into Swift code as proper types thanks to the implemented "Import as Member" proposal, although this would only work for simple classes without destructors. For destructors, this would probably need another class wrapper on Swift side that would call the destructor function from deinit. This would still not allow using C++ templates as generics, but it could be a start.
As far as I know, this is similar to what rust-bindgen is doing, although it's a bit easier for them thanks to availability of macros in the language.
Obviously, proper support in the Swift compiler itself would be great, but I imagine would require more expertise in the compiler itself. IIUC this would require extending the existing ClangImporter?
Another direction this could go is preparing a proposal for C and C++ calling convention attributes on Swift declarations (only non-generic Swift function to start with?). This would probably require such functions to be mangled by C++ rules when exposed to C++. I'd expect this to work similarly to the existing @objc and the unofficially supported @_cdecl attribute. Maybe we could have a single @ffi (name for bikeshedding) attribute that could be reused for interop with other languages, not just C and C++?
I'm really excited about the possibility of interfacing with C++ from Swift, as this would unlock building more powerful tools that interact with the Swift compiler directly. We have SwiftSyntax, which uses a mostly manually written C wrapper, but I can't wait to be able to use other compiler modules like AST and Sema directly for Swift. Who knows, maybe when that's all working, we could consider a possibility of a bootstrapped Swift compiler? 