When some other mod tries to read data.raw['storage-tank']['fluid-memory-unit'].pictures of your storage tank it will get:

{
  flow_sprite = {
    filename = "__fluid-memory-storage__/graphics/entity/nothing.png",
    priority = "extra-high",
    size = 1
  },
  fluid_background = 0,
  gas_flow = 0,
  picture = {
    filename = "__fluid-memory-storage__/graphics/entity/fluid-memory-unit.png",
    hr_version = {
      filename = "__fluid-memory-storage__/graphics/entity/hr-fluid-memory-unit.png",
      priority = "high",
      scale = 0.5,
      shift = {
        0.25,
        -0.0625
      },
      size = {
        256,
        256
      }
    },
    priority = "high",
    shift = {
      0.25,
      -0.0625
    },
    size = {
      128,
      128
    }
  },
  window_background = 0
}

See that only one of the sprites you set by using same table "nothing" gets proper sprite, while everything else gets literal 0. This obviously isn't a valid sprite.

I suspect Factorio serializer handles usage of this one table in multiple places by serializing it only once, but deserialization for other mods doesn't work properly...deserializing it as 0.

I suggest using table.deepcopy(nothing) instead of just nothing when you are creating storage tank prototype to work around this Factorio issue. I already tested this fix and it provided proper sprites to other mods.

The tables are not literal 0. This is a bug with the serpent library for factorio.

Proof: Here is the dump of factorio data: https://gist.githubusercontent.com/Bilka2/6b8a6a9e4a4ec779573ad703d03c1ae7/raw/2758ed720e42cdcd9e5c3b2708a0f51b38a92daa/Data.raw%25201.1.91

You will notice that this dump also has 0 values for all sound definitions.

I have fixed this issue in fluid memory storage. All instances of the nothing table are now separately instantiated. Thank you for the report.

Did this get reported as a Factorio bug?