The associations tab is already hidden if the site isn't multilingual.
As far as I know it's only the language select that is always shown.

all the more reason to remove this useless column and field

Actually the associations tab is hidden if associations is not enabled - it uses JLanguageAssociations::isEnabled();
which is a different and more specific check than the one i proposed

JLanguageAssociations::isEnabled() implies JLanguageMultilang::isEnabled()
https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/language/associations.php#L140

Now, about the RFC.
We have to take into account the fact that some 3rd party extensions may be using the language field without using our core language filter plugin. Therefore JLanguageMultilang::isEnabled() can't be the condition.

One solution I have been considering for a while is to create a new Global Configuration parameter. Obviously, when using our core mutilingual functionality, that parameter should be set (for example, enabling the core language filter plugin would automatically set that param if not done yet) and 3rd party multilingual extensions would also have to use it. (not B/C)

Now, practically, we have a lot of places where the field, list, filters, js, display/use Content Languages.
Which means a huge refactoring of the whole CMS in function of that new parameter afaik.

We have to take into account the fact that some 3rd party extensions may be using the language field without using our core language filter plugin. Therefore JLanguageMultilang::isEnabled() can't be the condition.

This is for J4 so we can break backwards compatibility and make it the conditions

Now, practically, we have a lot of places where the field, list, filters, js, display/use Content Languages.
Which means a huge refactoring of the whole CMS in function of that new parameter afaik.

so no reason not to do it then

Looks like you did not read carefully what I wrote;

We have to take into account the fact that some 3rd party extensions may be using the language field without using our core language filter plugin. Therefore JLanguageMultilang::isEnabled() can't be the condition.

We can't force any 3rd party to use our system plugin if they devise another way to implement a multilingual solution for Joomla.

JLanguageMultilang::isEnabled() means that the language filter system plugin is enabled, which would break any 3rd party wanting to devise their own solution without using it.

This is why I propose to use instead a global parameter which we also would use in our core implementation, i.e. for core JLanguageMultilang::isEnabled() would include that new param and 3rd party would ONLY use that new param to display all language-related fields, etc.

We can't force any 3rd party to use our system plugin if they devise another way to implement a multilingual solution for Joomla.

If they chose not to use the joomla system then they have to accept any consequences that go with that

JLanguageMultilang::isEnabled() means that the language filter system plugin is enabled, which would break any 3rd party wanting to devise their own solution without using it.

the exact same argument could have been used against using JLanguageAssociations::isEnabled() but it wasnt

This is why I propose to use instead a global parameter which we also would use in our core implementation, i.e. for core JLanguageMultilang::isEnabled() would include that new param and 3rd party would ONLY use that new param to display all language-related fields, etc.

All your arguments above can be used against this as well. you are just proposing moving your issue to a different part of joomla.

To my mind we have a multiligual plugin that we require to be enabled if your site is multilingual and we have an api point to identify that. we should move on and start to using it instead of finding meaningless arguments that say we must reinvent the wheel.

the exact same argument could have been used against using JLanguageAssociations::isEnabled() but it wasnt

You definitely do not (want to?) understand.
JLanguageAssociations::isEnabled() is totally linked to our core multingual system and JLanguageMultilang::isEnabled().

It may not be used by some existing or to be proposed 3rd party solutions which would prefer not using our core solution.

I am not making an argument. I am not against this RFC, but it should be done imho with a new API which is a Global Config parameter.

Your reply is not necessary.