Much of the design of Boost.System (which went on to become <system_error>) has been retained in proposed <system_error2>, so an approximate map between <system_error2> and <system_error> and Boost.System can be given:

C++ 17 <system_error>	Boost.System	Proposed <system_error2>
std::errc	boost::system::errc	experimental::errc (almost identical)
std::error_category	boost::system::error_category	experimental::status_code_domain
std::generic_category	boost::system::generic_category	experimental::generic_code_domain
std::system_category	boost::system::system_category	One of: experimental::posix_code_domain (POSIX systems) experimental::win32_code_domain (Microsoft Windows) experimental::nt_code_domain (Microsoft Windows)
std::error_condition	boost::system::error_condition	No equivalent (deliberately removed as hindsight proved it to be a design mistake leading to much confusing and hard to audit for correctness code)
std::error_code	boost::system::error_code	One of: experimental::status_code<DomainType> const experimental::status_code<void> & experimental::status_code<erased<intptr_t>> (aliased to experimental::system_code) experimental::errored_status_code<DomainType> const experimental::errored_status_code<void> & experimental::errored_status_code<erased<intptr_t>> (aliased to experimental::error)
std::system_error	boost::system::system_error	One of: const experimental::status_error<void> & experimental::status_error<DomainType>

As is obvious from the above, in <system_error2> one must be much more specific and accurate with respect to intent and specification and desired semantics than with <system_error>. Much ambiguity and incorrectness which flies silently in <system_error> will refuse to compile in <system_error2>.