For flexibility, this would effectively require a second, invisible copy of the ship in memory, with meta data for each block.
This invisible copy would only need to consist of "meta blocks" vs. normal, visible blocks in the normal copy of the ship. Then it is very flexible for background ship things, like RGB(A) coloration, invisible logic connections or lighting hints or sound effect hints or... etc., etc., etc.
If a person did not set a lot of RGB coloring on their ship, the invisible copy would be very lightweight. People who use RGB extensively would use a lot more RAM.
Theoretically, you could put RAM control in the hands of the server admin by restricting the use of meta block types via XML. Want a less colorful pallett, but easy on the RAM? Disable RGB metablocks and/or meta-logic blocks. Want better lighting and ambient sounds at the cost of using more RAM? Enable lighting and sound meta blocks. Want to prioritize RAM? Disable all block effects and ship copies. Easy.
If the game needs to implement multiple meta blocks in the same coordinate, the game simply makes another invisible ship copy and places the second meta block on this copy. Then the game just chains through all the copies available, compounding effects for any given visible block. Massive changes to the blocks in a ship, such as missile damage? Once the blocks that need to be removed are figured out, those same blocks should be pretty easy to remove from all copies at once.
