Thank you for opening the PR!
My biggest concern is that same config file will be created for every optimised svg file
Also some test would be nice

I've modified the patch to memoise the config file so it's only created once.

As to testing it would be nice but I'm struggling to figure out how to test it... Are there even any tests that run svgo conversions? I can see there's a test svg file but I can't see what uses it? Even then I'm not sure how you'd test that this is working let alone testing the fallback path when we only have a current svgo.

I tried testing how it works and understood that current solution will work only for disabling plugins included in preset-default, as enabling not included plugins (for example removeScripts) will show a warning from svgo that they are not in the preset and should be added directly to plugins to define order.

Simple way to handle this is to just list all enabled plugins after preset-default in order, but I'm not sure if it is good enough, as plugins can (and some need to) be configured. Less restrictive and more precise (but also more involved/complicated) seem to be either allowing to specify complete config as a blob, which should be ok in yaml, but cumbersome as a CLI argument, or allowing to specify config path, which splits config into two files. Or even allow both.

What do you think?

You're definitely right that enabled plugins should be listed after the defaults rather than as overrides in the default set, so I've made that change.

You're also right that in principle plugins may need to be configured, but I don't think that was possible before so as it stands I htink this now restores the legacy functionality? A future enhancement to allow plugins to be configured is definitely a possibility though.

I understood that using tap doesn't close the file, so I add it myself and also a changelog entry

Thank you!

Included in 0.32.0