I totally agree on md_5 here. A limit just makes things more complex for little to no benefit.

Same as with the max aliases for collections (SPIGOT-5881) the limit has been removed to ensure compatibility. An option could be added, but I think for compatibility the default would have to be off (or high) anyway at which point I don't see a plugin toggling it on. Maybe that could change in a future major version, but on the other hand configs are more or less trusted and also developers don't like artificial limits in the API

> I believe it would be best to expose a method which can change this limit to plugins, but importantly, not raise the default. My opinion is that there are far better solutions for data storage than using YAML, especially for files over 3MB, be it a database, 'minified' JSON flat-file, and so on. By raising the default, it doesn't discourage plugin developers from exploring an alternative.

I agree with this point and plugins should seriously be discouraged from using YAML as a means of storage. There are, however, some plugins that do make use of very large configuration files for good reason. Things such as MythicMobs or DeluxeMenus need access to extremely large config files. The reason those plugins are as popular as they are is because their extensive configurability makes the plugin rather flexible. I think if we don't expose a way to increase the limit (maybe via MemoryConfigurationOptions), we're unnecessarily handicapping thoroughly configurable plugins.

> Are you sure there was a limit at all?

You are correct, the limit as a whole is a recent addition: https://bitbucket.org/snakeyaml/snakeyaml/commits/72dfa9f1074abe2b8a6c8776bee4476b0aed02e3
It was initially at ~100k characters and later increased to 3M characters. I accidentally interpreted it as a reduction from 100M to 3M characters.

> (the previous limit was 100mb).

Are you sure there was a limit at all?

Can you provide a code reference. The commit you linked (which I think was not in megabytes anyway) wasn't in the prior release, it looks to be a new addition. See, eg, https://bitbucket.org/snakeyaml/snakeyaml/src/snakeyaml-1.31/src/main/java/org/yaml/snakeyaml/LoaderOptions.java

I believe it would be best to expose a method which can change this limit to plugins, but importantly, not raise the default. My opinion is that there are far better solutions for data storage than using YAML, especially for files over 3MB, be it a database, 'minified' JSON flat-file, and so on. By raising the default, it doesn't discourage plugin developers from exploring an alternative.

If this is to be implemented, snakeyml will most likely have to be bumped to 1.33 as the current usage of it does not properly forward the yamlLoaderOptions of the yaml instance.

See: https://github.com/PaperMC/Paper/blob/master/patches/api/0397-Expose-codepoint-limit-in-YamlConfigOptions-and-incr.patch
See: https://bitbucket.org/snakeyaml/snakeyaml/pull-requests/31/issue-553-honor-code-point-limit-in
See: https://bitbucket.org/snakeyaml/snakeyaml/src/49e794037c6be07053ce930f71f9c31b09180920/src/main/java/org/yaml/snakeyaml/Yaml.java#lines-559