shouldn't this task can be covered overloading InstallerScript class ?

@alikon

shouldn't this task can be covered overloading InstallerScript class ?

I have already addressed that:

The latter transfers the responsibility of updating Joomla's internal structures upon extension update to the extension developer, which is as unfair an expectation as it is dangerous.

I will try to further elucidate the point.

Joomla MUST do everything necessary to correctly apply an extension update. I believe this is self-understood. If I have to explain that we might just as well close up shop and take up knitting instead.

When Joomla fails to do that there must be some valid reasoning behind it. For example, not removing existing internal extension directories (think src/Models/Foobar in a component, for example) is annoying, but understandable. Doing otherwise might end up deleting generated files in inner directories, causing more problems. Hence the delteFiles() method in the InstallerScript (which, by the way, is code I wrote for FOF 2 and George copied to Joomla with my permission, so don't even think about lecturing me on what was the intention behind my own code).

What we are talking about here is categorically not anywhere near the realm of valid reasoning. There is no sensible use case where a template is updated to become inheritable but you want its template style to remain non-inheritable. This will break the template display in the frontend. Therefore, Joomla has a bug which must be fixed. That should have been the end of the discussion.

Even if you don't want Joomla to fix its obvious bug, what you are asking site integrators and template developers —the people who make templates and don't, can't, and shouldn't need to know the inner workings of Joomla at the detail level core contributors do— is to come up with code which in its most simplified form looks like this:

use Joomla\CMS\Factory;
use Joomla\CMS\Installer\InstallerAdapter;
use Joomla\CMS\Installer\InstallerScript;
use Joomla\CMS\Installer\InstallerScriptInterface;

defined('_JEXEC') or die;

return new class extends InstallerScript implements InstallerScriptInterface {
	protected $myTemplateName = 'mytemplate';

	protected $minimumPhp = '8.0';

	protected $minimumJoomla = '4.2.0';

	public function preflight($type, $parent): bool
	{
		return parent::preflight($type, $parent);
	}

	public function postflight(string $type, InstallerAdapter $parent): bool
	{
		return true;
	}

	public function install(InstallerAdapter $adapter): bool
	{
		return true;
	}

	public function update(InstallerAdapter $adapter): bool
	{
		$this->setDboFromAdapter($adapter);
		$this->fixNerfedStyles();

		return true;
	}

	public function uninstall(InstallerAdapter $adapter): bool
	{
		return true;
	}

	private function fixNerfedStyles(): void
	{
		$db    = Factory::getContainer()->get('DatabaseDriver');
		$query = $db->getQuery(true)
			->update($db->quoteName('#__template_styles'))
			->set($db->quoteName('inheritable') . ' = 1')
			->where([
				$db->quoteName('template') . ' = ' . $db->quote($this->myTemplateName),
				$db->quoteName('client_id') . ' = 0',
			]);
		$db->setQuery($query)->execute();
	}
};

This is an unrealistic expectation.

Finally, Joomla explicitly excludes the database schema from its semantic version promise. So, no matter what we come up with in third party code, we are guaranteed that it will randomly break. Therefore the mere suggestion we should be mopping after Joomla's mess and burden ourselves with it forevermore is preposterous.

Valid issue

You are actively harassing me by reopening the issues I have closed because your organisation has bullied me away. What kind of dystopian hell is this project?