Otherwise this is a good start and has my vote. I would like to sell objects with moddable contents, yet prevent the buyer from messing with the design, or simply destroying the object's visual aspect, then wanting it fixed!

I sell beds, and I want the user to be able to add things to them (aftermarket plugins i sell), want them to be able to edit some notecards (configuration ones).

This would allow it.

However, this flag is only related to modification, it occurs to me that there could be one for copying as well, but basically even with modify contents set to false, you can still copy things out of the object, you just can't remove the original. This allows open-source scripts that were correctly set to copy/mod to still be 'fairly' used within an object. For example;

In the case of one of your beds, you might set-up a vendor in a low-prim area where you can't permanently rez copies to try. You could however have a vendor that passes out demo objects. These demo objects may use an open-source "try-before-you-buy" script which lets the users rez a full-featured bed that will destroy itself after say 10 minutes. This open-source script would be placed in your object and would have full-perms set, however the demo-object itself has modifiable contents set to false.

If you followed that wordy example then you now have an object with an open-source script inside it. The script is full-perms as open-source scripts should be according to any license. Your object however does not permit the user to modify its contents. What does this mean? All it means is that I can't rename, delete or remove the script (or anything else in the object). However, as the script is copyable, I can still copy it into my inventory, and modify that copy to my heart's content.

Hopefully that clarifies the case of an object with unmodifiable contents from a 'fair-use' standpoint.

It does however show inflexibility in the notecard point which is one I'm interested in too. I'm now thinking (referring to my table) in terms of whether a modifiable child, in a parent object that has modify contents OFF, should be modifiable if it has its own modifiable contents flag set. For example:
I've a box with a notecard in it.
The box is unmodifiable, as are its contents.
The notecard is modifiable, as are its contents.

As proposed this feature actually would NOT allow you to edit the notecard; it's possible you could open it up, but when you went to save it it would be seen as a modification of the box and would cause an error. I'm thinking now that the terms of modifiable contents may need to change ie -
modification of an object's contents is seen as:

• Attempting to remove/delete an item in the object
• Attempting to rename an item in the object (this could break scripts which this feature is intended for)
  It does not however apply to saving a modifiable object within it

In essence; the notecard's permissions have precedence over their own contents, and the ability to copy the notecard from the unmodifiable box.
This allows for the case whereby an object contains a number of unmodifiable scripts, with a modifiable notecard. By having the notecard sets /it's/ contents to modifiable, then it can still be edited, but the object cannot be damaged, destroyed or made insecure by removing any of the scripts.

This however raises further issues that an open-source-script you happen to be using could be edited by an end user. This is not desirable as they could cause untold damage in this way.

This has been a wordy comment, but hopefully it makes some sense. I'll maybe add a revised table to show what I mean when I have the time. Or may require being combined with the 'removable' flag Argent Stonecutter suggested. With that it would be possible to have an object's contents modifiable, but a core of scripts un-removable, thus you can add things but cannot break the object. This has it's own pitfalls however.

Perhaps modifiable contents should not apply to scripts within the object. ie they can always change the contents of the object just as they can change textures etc. This was they can enable allowed drop for things to be added, and process these.