Clarification on pointer to member of base

Question

Experimenting with member pointers, I came a across some unexpected behavior. I need to ask whether this behavior is a UB or undocumented behavior or just a compiler bug. The test was run on Visual Studio 2022 with msvc toolchain as well as llvm. I asking for pointers to reputable references on standard or platform-specific behavior. And I'm afraid I can not accept a mere don't as an answer. The problem in question is the result of an oversimplification of some library features.

consider simple metadate listing below:

template<typename T>
concept has_foo = requires{ {&T::foo}; };

template<typename U>
requires has_foo<U>
constexpr static auto foo_address = &U::foo;

template<typename U>
requires has_foo<U>
using foo_type = std::remove_const_t<decltype(foo_address<U>)>;

Constraining the templates does not change the results - but it is there for furthur expressiveness. We are going to test the following baz classes:

struct bar {
    int foo(){};
};

struct baz1: bar {
};

struct baz2: bar {
    using bar::foo;
};

struct baz3: private bar {
    using bar::foo;
};

the test function to be used is:

template <typename t>
void foo_test() {
    endl(std::cout << std::boolalpha << std::is_same_v<decltype(&t::foo), foo_type<t>>);
    endl(std::cout << typeid(&t::foo).name());
    endl(std::cout << typeid(decltype(&t::foo)).name());
    endl(std::cout << typeid(foo_type<t>).name());
};

msvc fails to compile for baz3 with hard error on foo_address and foo_type, while clang accepts it. I need to learn the stance of standards against such behavior.

Thank you all, FM.