As you probably know, COS files placed in a folder in the bootstrap directory are used to create new worlds, so if someone places your COS in the bootstrap every time they create a new world they will get your CAOS creation.
This has some advantages over .agent files in that they do not need to be individually injected, and will appear in every new world automatically, but ironically this can be a disadvantage too. If you are overwriting a COS file that shipped with the game then you better hope you didn't make any mistakes ... and you better make sure you provide a means for the player to get back the default behaviour ... because if there are any problems they will occur with*every* world created and could lock the user out of the game.
There is a little publicised function of the bootstrap folder that could help with COS distribution, specifically it works like this:
This means it is possible to create a COS file that can be added to all the worlds a user has, not just new worlds, by creating a new folder within the bootstrap folder.
So how does this help the user?
If you intend to create a COS file for others to use you should provide instructions (or use an installer) so that the user creates a new folder in the bootstrap directory named after the object in question. Then whenever a world is opened the COS will load its contents into the world. Where this is an improvement over just placing it in the 001 World folder is that it is now easily identifiable by the user, and they can delete that folder if they want to get back to a default state.
Why take this approach?
At CLabs we have to deal with the support issues that arise from 3rd parties ... and in some cases we have to restore a users world to its default setting if they cannot identify what has been added. To do this we will provide the user with a ZIP file containing all the default COS files in the bootstrap, and so all 3rd party COS will be removed.
If 3rd party COS are kept in a named folder then it makes it much easier for the user, and also for support, to find out what is causing the problem.
Is there anything to watch out for?
Yes. If you intend to distribute a COS that overwrites an existing default COS then you need to write the install part in such a way that it stops execution of the original object and then removes it. If you just recreate the default COS in a new file and place it in the folder in the bootstrap you will find that you then have 2 versions of the object (which is probably not what you want). This method is much better than asking the user to manually remove a file from the Bootstrap folder, because they can easily get the world back to its default state by removing your new folder.
So in summary: