Was the ABI break between 14.1 and 14.2 in std::_Hash and derived containers intentional?

I am working with a library that uses std::unordered_map and std::unordered_set in its exported API. The library is compiled with VC 14.16. When an application compiled with 14.29 is linked to this library the linker fails to resolve std::_Hash::_Insert_new_node_before, which exists in the 14.29 xhash header but not in 14.16.

Is this ABI breaking change intentional?

Aside from not using any STL containers in a library API, is there some known workaround for this where we could continue to compile the library with 14.16 and applications with 14.29? We can break our ABI if necessary but not our API at this point.

Do the ABI stability and compatibility guarantees in VC 14.x extend to the STL included with these versions?

Thanks,
Jake

Start by comparing the VC 14.16 and 14.29 xhash headers, focusing on std::_Hash::_Insert_new_node_before and the exported unordered container API. Determine whether the symbol difference is an intentional ABI change and document any supported compatibility workaround; the issue is done when the ABI guarantee and migration path are clear.