> I'm sorry, but I fail to connect your response with Jason's comments.
> This technical discussion would benefit from some specifics from you

OK, I will try to give some quick responses per your request.


> Let's say we do what you say. We define that these functions are
> non-static in every way. So... what is the type of this:

> ```
> struct foo
> {
> void ex_mem(this foo self);
> };
> ```

> That is, what is the type of `&foo::ex_mem`?

> If this function must in all ways be a regular non-static member
> function, then that `self` parameter needs to go away. After all,
> member pointer syntax is of the form
> `ReturnType(ClassName::*)(Parameters) Qualifiers`. The implicit `this`
> parameter is defined by the `Qualifiers`, not the `Parameters`.

> So now a user needs to stick the first parameter in the `Qualifiers`
> section. Personally, I would find this to be *incredibly* confusing.
> The parameters of a function declaration should match the parameters
> in a member pointer. You shouldn't have to shuffle them around for no
> reason.

> Note that the current proposed behavior doesn't have this problem. The
> parameters in the declaration are always the same when used as a
> function pointer.

You say that the form of the static function pointer syntax matches better the form of the proposed function declaration syntax, and for that reason you (presumably) think that the proposed function declaration syntax should be assigned to a new kind of member functions as proposed in the paper.
I think there are several ways to comment on this. I will comment with an analogy: based on your argumentation, one might say that the class objects that define operator() should be defined in the standard as a special kind of function, because the syntax you use to call them is the same as the function call syntax. Similarly, the function pointer should also be defined as a special kind of function because you use it with the same syntax.

struct S{ void operator()(int){} };

void foo(int){}

int main()
{
    S v{};
    v(0); //struct S is a special kind of function

    auto p = &foo;
    p(1); //function pointer is a special kind of function
}

I believe that most people will disagree with defining callable class objects and function pointers as kinds of functions, because they are not functions, even if we call them in code with the same syntax as functions.

> You keep saying that it is "complexity" but you never explain *why*
> this is "complexity". Consider the above: I went into detail as to
> exactly where your proposal would add complexity.

The complexity I am referring to relates to concepts defined in the standard, not to the shape of the code.
Currently we have two kinds of member functions defined in the standard. If you add one more hybrid type, then you have made the overall conceptual framework more complex.

Like I said in the previous message, the basic problem underlying your argumentation is your belief that we should ignore the standard and its concepts because those things do not concern the average C++ user. Your argumentation is focused entirely on the shape of the code and makes no reference what so ever to the concepts that people learn from the text of the standard.