With the addition of storing scripts in .minecraft/config/carpet/scripts folder, does it still makes sense to have that option in config, and not assuming if a script is in the world scripts folder it needs to be loaded.

scripts in the appstore all tend to have that set, possibly to avoid - I put it in the world files, but script doesn't load. - yeah, you not only need to enable scripts loading in the carpet settings, but also edit that file I told you to download to load automatically.

On the same note - scripts autoloading should be on by default? if you don't have any scripts it won't have any effect so its still voluntary and have no effect by default, and scripts from shared .minecraft/config won't be loading automatically.

The main reason for that, tbh, is that I typically had several scripts I was testing at all times and having all of them load automatically would be super annoying, but now with a better location for shared and non-automatic apps location - it makes sense that whatever you put in the world/scripts floder, just works if you put it there?

It makes sense for survival, but no so much for tools, I'm not sure I'm convinced. Maybe set the carpetrule autoload to true by default, but sill have a way for scripts in the scripts folder of the world not automaticaly load. Maybe make the config work by the negative? __config() -> {'Autoload'-> false} is required for it not to be automaticaly loaded?

Honestly I always "hated" the fact of having to specify a script to load itself automatically and load it for the first time.
80% of the scripts always need to be loaded, as they are used as "mods / datapacks" and if you had lots of them and you wanted to start a new world with the same scripts you always need to load them for the first time...

In my opinion commands like /script install <name> [globally true|false] and /script uninstall <name> [globally true|false] might be really useful!
This ipotetic command can load/unload permanently (install/uninstall) a script that has __config->{'installable'->true} and it will stay loaded.

The scripts in the world folder could automatically install for the current world (if they are installable); stored scripts could need to be installed manually in the world instead.

The globally boolean could be useful to install a stored script in all your worlds.
[If in a LAN server, only the owner can manipulate this bool]

With those new commands the /carpet ScriptAutoload rule could be removed, on my opinion...

I think the stay_loaded property as false can be useful in multiple situations, mostly when you are just trying to set/configure something on startup, but I'd say that happens less than 10% of the time. Also manually disabling it can also be a way to disable automatic start of certain apps, although with some side effects (maybe another property like autoload for that?).

I'd like having stay_loaded defaulting to true, since right now it's just a small "annoyance" you have to change almost every time you create a new app.

Unsure about autoloading by default, though. At the same time I see the benefits of it defaulting to true, but some situations where you may not want to have it. Probably in favour, since it wouldn't do anything as long as you don't explicitly place a script in the world, and if you don't have the carpet.conf with defaults you probably also don't have scripts.

I always needed a space to store scripts to work on and now minecraft install global space is perfect for that. I would assume that if someone sent me a world with scarpet apps in them they should 'just work'.

scriptsAutoLoad still makes sense in case something is wonky and you want to disable apps from messing up even with your startup, that's why there is enableCommandblocks in server properties - to be able to log into worlds with messed up commands.

Having stay_loaded and be able to set to false makes also sense, to what altrisi says - as indicating its still in 'dev mode', still - to get the config script needs to be run at least once.

So stay_loaded and scriptsAutoload still be there, just flip their defaults to the opposites?

that's a lot of thumbsups. Let it be.