Need to decide whether default plugin params should be included in SQL files or not.

If there's already a config in the SQL files then it should stay there, if there isn't we shouldn't add it because the PHP code should be reliably setting default values (matching what's defined in the XML schema) and using those for cases where a given param isn't set.

Long term, we shouldn't really need any params in SQL files and I'd say putting them in there should be an exception rather than a standard because this means the core install isn't using the default form settings for some reason.

Plugin configs don't seem to be needed for core and, given how random they are, they're not much use to 3rd parties either.

What about module configs in #__extensions table? Do they actually serve any purpose?

And what should we use as default value for params in the table? Empty string or empty object ({})? I see a mix of both.

Plugin configs don't seem to be needed for core and, given how random they are, they're not much use to 3rd parties either.

No, but as someone who favors strict typing, I do think it's better in general if the code and the form are consistent on typing (so a numeric value should always be configured in the form to be stored as an integer or float and converted as such when the param read in whatever PHP code uses it). Same for every parameter in every location, regardless of whether it's used by "external" sources or only used within the extension.

What about module configs in #__extensions table? Do they actually serve any purpose?

Nope.

And what should we use as default value for params in the table? Empty string or empty object ({})? I see a mix of both.

Default should be something that can safely be put through json_decode() since we have code paths that do zero validation and blindly try to decode whatever data is given. null and '' both give syntax errors with json_decode(), so '{}' looks to be a sane default.

Can this be closed now as resolved by the pr from @SharkyKZ ?