EWG Discussed this on Monday in Varna, and the following poll was taken:

EWG agrees with the 'first' CWG proposed solution from the November '21 rationale on CWG 1699, that friend functions defined in a class get access to the private/protected members of the class, however friend functions NOT defined in the class definition do not.

However, further discussion lead to further explanation of the inconsistencies, and EWG determined that a paper (written by @jfbastien, Jeff Snyder, et al) explaining the following examples should be presented later in the week:

  class c {
    class n {};
    friend struct s;
  };

c::n g() { // #4 
  // 'n' accessible here? 
}
  struct s {
    friend class c::n;          // #1
    friend c::n g();            
	    friend c::n h();            
    friend void f() { c::n(); } // #3 (EDG/MSVC Reject, Clang/GCC Accept)
  };
  
c::n h() { // #5 
  // 'n' accessible here? 
}
3 disallowed
3 &4 allowed, same meaning (no matter where 4 is)
3 & 5 allowed, same meaning (5 only allowed if 'after' friendship)

Sad paper is encouraged to consider templates (class template, function template, and member function templates), as well as modules.

Note that there's a similar issue that is usually considered to be part of CWG1699: if f is a friend of T, does f also have access to private members of the class that T is nested withn?

class A {
    static int x;
    class B {
        friend int f() { return A::x; }  // OK?
        friend int g();
    };
};

int g() { return A::x; }  // OK?

It would be good if the paper would also discuss this case.

The discussion included a request to discuss templates in modules as well.

EWG St. Louis: @villevoutilainen volunteered to write a paper.