I think p14.6 specifies behavior of implementations, while the example shows potentially invalid use in user codes due to such behavior, so there's no contradiction.

I think p14.6 specifies behavior of implementations, while the example shows potentially invalid use in user codes due to such behavior, so there's no contradiction.

My issue is that 14.6 says except within the default arguments, so it seemingly excludes the behavior described in the example.

The recursive call to g(false) should create a closure type inside of g, presumably.

except within the default arguments

It's saying that the closure types are the same except in that case.

except within the default arguments

It's saying that the closure types are the same except in that case.

It's not saying that; the quote I've posted is just one of many requirements for the ODR not to be violated.

After discussing it with a handful of other people, we managed to wrap our heads around it. A much better example would be:

inline void g(void (*p)() = []{}) {}

inline void g2() {
    // ill-formed, no diagnostic required
    // use of default argument defines a closure type outside of g2
    // which is not the same across TUs
    g();
}

So the current example also requires http://eel.is/c++draft/basic.def.odr#14.11 to make sense.
Is that right?

So the current example also requires http://eel.is/c++draft/basic.def.odr#14.11 to make sense. Is that right?

Not really. g making that recursive call means that []{} is introduced into its definition for ODR purposes, but that doesn't create any additional problems. We violate the ODR with lambdas when they don't have the same closure type in every TU; that's the actual issue.

It may look like p14.11 is relevant to the example with g, but it isn't. The problem is where our closure types are located.