I think I'd go down the route of more complicated scripts attached to the objects. If you want a switch that you can turn on and then turn off, the on switch would have script to replace the object with the of switch and vice versa. Something like: "remove(me)|createobjecthere(12)" 12 being the id of the off switch.
As for the same 'class' of object resulting in different actions, I did see this as a case of creating an object for each and every interaction, although remember that two objects can point at the same image. The reasoning here is that a) you need to write the script anyway (in your example against the tile), and why not keep all scripts in objects? I did add names to objects to try to help this duplication of objects, and I also reasoned that the number of objects that would need to trigger a separate item would be low enough for this to be acceptable.
If we've got a common set of items that we'd like to reuse many times, maybe we need to do as we have with keys and doors?
Not entirely sure on this, I'm still inclined to think keeping it in the object is the way to go, will sleep on it...
As for the same 'class' of object resulting in different actions, I did see this as a case of creating an object for each and every interaction, although remember that two objects can point at the same image. The reasoning here is that a) you need to write the script anyway (in your example against the tile), and why not keep all scripts in objects? I did add names to objects to try to help this duplication of objects, and I also reasoned that the number of objects that would need to trigger a separate item would be low enough for this to be acceptable.
If we've got a common set of items that we'd like to reuse many times, maybe we need to do as we have with keys and doors?
Not entirely sure on this, I'm still inclined to think keeping it in the object is the way to go, will sleep on it...