This is exactly what I was trying to achieve here hotwired/turbo-rails#594. I was barking to the wrong tree 😅.
I stepped into a use case recently where this Turbo-Action header on the controller could be very helpful. Let me draw the context with my case:

• Devise has a helper called store_location_for used on controllers to keep track of not logged users navigation and redirect them to the last location after a login/signup.
• Now suppose we have a page with two turbo-frames, one that is updated by a button with data-turbo-action="advance" and a lazy loaded turbo modal.
• If user visits the page, clicks the button and open the modal, 3 requests are triggered, I'll call them A, B and C respectively. - Then the user use our login button, log himself and the situation happens.
  • If we register all the request paths on controller, the user is redirected to path C, an HTML just with a turbo-frame with the modal info
  • If we avoid to register all turbo-frames using the turbo_frame_request? helper, the user is redirected to A. But B is a valid page and when he clicked the button from A a "navigation" occurred
  • In this case, expected result is being redirected to B. So we want to register A and B requests, and ignore C. But how could we identify if a frame request is causing a "navigation" or not.

On this last point is where Turbo-Action header could be very helpful as we could easily write a helper checking if a turbo frame request triggers an URL update ("advance" and "restore"), using this we could easily select which paths to store and which paths to ignore. Is this one planned at short term?
When this one gets merged the helper on FrameRequest from turbo-rails could be a good addition.