? at least not without bigger re-thinking of what a "page heading" is, and inherently how that specific parameter interacts with the entire request-response cycle (and this would theoretically get into other system elements too).

Part of the problem is it is rendered as part of the component area, after dealing with parameter merging, which means to figure out what the heading is needs to go through the component as part of the normal request-response cycle. Moving it to a module forces you to put that data into some kind of request specific state so that a module can access the data processed by the component during the primary execution path of a request. You then also have caching to deal with; with it enabled you don't get past Joomla\CMS\MVC\Controller\BaseController::display(), so the model that deals with the parameter merging will never be executed which basically means the module would only use the heading defined in the menu item except for the one request that gets triggered when the cache has expired and needs re-built.

(Note this same type of problem in theory exists with Joomla\CMS\Pathway\Pathway and the breadcrumbs module, which is conveniently worked around in the oh-so-aptly named Joomla\CMS\Cache\Cache::getWorkarounds(), a name which should imply that some kind of architectural issue is being hacked around)

Thank you @mbabker that is very insightful. It all makes a lot of sense. For me it's just about layout, but there is always a code process that I don't understand enough about to foresee. Let's see if anyone else gets involved - but only to see if there is a mass outcry of support for the idea.

I can't see it happening. I'll close this in a week or two if nobody comes. Thanks for taking the time to explain.

Theoretically... this would be possible with getWorkarounds?