非模块化第三方库与C++ Modules的ODR冲突解决问询

每过一两年我都会尝试用C++ Modules，但每次都踩坑——以前大多是编译器实现的问题，这次感觉是规范本身的锅，找不到解决办法。

假设有个第三方库的头文件foo.hpp，里面包含了<string>。但因为特殊宏用法之类的原因，这个头文件没法编译成header unit，只能通过#include引入。我的问题就出在同时使用这个库和<string>的时候。

思路1 #

module;

#include <foo.hpp>

export module A;

import <string>;

...

问题：foo.hpp里已经包含了<string>，但导入<string>的header unit时不会触发头文件保护，直接导致ODR（One Definition Rule）违反。

思路2 #

export module A;

import <string>;
#include <foo.hpp>

...

分析：导入<string>的header unit会定义对应的宏，所以当foo.hpp再包含<string>时，头文件保护会生效，解决了ODR问题。但副作用是foo.hpp的所有内容都会被定义为模块A中的实体，由此引发各类问题。

思路3 #

module;

#include <foo.hpp>

export module A;

...

出发点：既然foo.hpp已经包含了<string>，没必要再单独引入。但这个方案在复杂场景下不适用——比如导入其他导出<string>的模块时，无法进行扩展。

思路4 #

module;

#include <string>
#include <foo.hpp>

export module A;

...

这个方案能正常工作，但存在明显弊端。

核心问题 #

有没有解决这个问题的方法？难道C++ Modules根本没法和非模块化第三方库配合，直接失去实用价值了？

注：我想了解C标准中的规定，而非具体编译器实现的做法——毕竟各实现对模块的处理仍在完善中。不过也接受这类答案：“C标准不允许，但各实现正协作推出变通方案”。

内容的提问来源于stack exchange，提问作者sudgy