First I'll introduce the initial motivation behind this feature. The
function 'std::async' returns an 'std::future' object, and the
destructor of 'future' blocks until the spawned thread ends. So if you
had code such as the following:

    for ( unsigned i = 0u; i < rows; ++i )
      for ( unsigned j = 0u; j < cols; ++j )
        std::async( EntryPoint );

Instead of running (rows*cols) threads concurrently, the above code
snippet will run the threads consecutively, as you can see in the
following GodBolt:

    https://godbolt.org/z/h3Y4f1jGn

You can see in the above GodBolt that the entire program execution
time is approximately 1 second.

But if we apply the unary operator '%' as follows:

    for ( unsigned i = 0u; i < rows; ++i )
      for ( unsigned j = 0u; j < cols; ++j )
        %std::async( EntryPoint );

we can extend the lifetime of any PRvalue until the end of the
function. The two variables, 'rows' and 'cols', don't even have to be
compile-time constants, as this new feature uses 'alloca' under the
hood to allocate space for them on the stack. So now the execution
time is down to 64 milliseconds:

    https://godbolt.org/z/PGqW45nG9

When the function exits, either by a 'return' statement or the
throwing of an exception, the destructors of function-bound objects
are executed in the reverse order of their construction. This is
achieved under the hood by means of traversing a linked list stored on
the stack (which again was allocated with 'alloca').

So what is this feature good for? Well you can spontaneously lock a
mutex at any point in a function:

   void Func(void)
   {
      if ( a )
      {
         if ( b )
         {
             if ( c )
             {
                %lock_guard{ my_global_mutex };
             }
         }
      }

      DoSomething();
   }

Here is the feature thoroughly torture-tested:

    https://godbolt.org/z/aMob4Yndq

And here is the entire compiler patch up on Github:

    https://github.com/healytpk/gcc-thomas-healy/commit/tag_classalloca

Personally I think function-bound objects are pretty cool. And you should too.