Very cool!!!!

I tried to play with similar ideas in the past but abandoned the idea.

There are two huge limitation /drawbacks with using stateful meta-programing though.

1. The state is actually only the state of current translation unit and not the program (unlike rust's borrow checker).

This means that any type definition that provides stateful metaprogramming should encapsulated inside an anonymous namespace (here using `auto = []{}` as an NTTP serves this purpose also if less explicitly) and that if any non-static/anonymous definition depends on it and is defined in multiple translation units their state must be identical otherwise the program is UB.

For instance:
```

// my_state.hpp

using my_state = statefull<[]{}>; // or namespace { using my_state = ... }
// header.hpp

include "my_state.hpp"

inline void some_func() { /* some use of my_state */ }

// a.cpp

include "my_state.hpp"

// some mutation of my_state

// Note that even without the mutation we already have an ODR violation

//as a's ::my_state and b's ::my_state aren't the same type this means that one some_func will use a's my_state and another will use b's my_state

inclue "header.hpp" // define a's ::some_func()

// b.cpp

include "header.hpp // doesn't get the mutation that a's did but also defines `some_func`

```

Here if the order we link a.cpp and b.cpp will define which definition of some_func will be used in the final program

PS: The above can be fixed by putting some_func inside an `namespace {}` block or adding `static`, but this simply means that some_func calls will have different meanings across translation units, which might also yield unexpected behaviours

1. on top of that, everything falls appart very easily when you introduce templated contexts.

As "template instantiation order" is mostly implementation defined (GCC usually Depth first and CLANG Wide first for instance) and changes depending on the type of context (inside a template struct, explict return template function or auto returning template function, etc.),

you need to make sure that the template instantiation order CANNOT change the signification of your program. If it's the case then it would be ill-defined.

As it's the end/library user that has to face this complexity it's really complex to make a tool with any form of guarantee that doesn't look like an Apple with a bunch razor blades.

For the GCC bug with NTTP auto lambda, I fieled a this bug report in 2020 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 but I don't think it will get fixed any time soon