Thanks Jarek I think the settings intermingling is independent from the problem you're concerned with. I can see how it would be desirable to define the executor interface more robustly, and to allow core to not care about k8s version (so that provider can use whatever k8s version it likes). But this is really a separate issue.
The issue I'm concerned with is that we have a defined way to configure hooks and operators Airflow: (1) the Airflow Connection or (2) direct config through operator or hook params. We do not do this via the `airflow.cfg` file. Resolving this inconsistency does not solve the problem you are concerned with; but it rectifies a user-facing inconsistency and a source of confusion. Whether the K8s executor is ever moved out of core or not, it will remain desirable that KPO only takes configuration from Airflow Connection or direct params, because that's how things are done in Airflow. The core `[kubernetes]` settings should apply to the executor but not the operator or the hook. And indeed, by and large, this is the case already; there are just a few `airflow.cfg` settings that affect KPO and the vast majority do not. WDYT?
