Thinking about this a little more: I think it would be ok to use unique IDs within the same file.

In the scenario of:

```
ff.tree['data'] = np.array([1, 2, 3])
```

the new data will have a new unique id and that unique id will have to be updated in the tree, so it really makes things no better or no worse.

In the case of external references, it's more complicated.  It is starting to make me think that external references to anything but the first block is tricky enough to disallow.  If the library is taking control of the whole situation and writing everything out at once, it's perfectly sane -- but if any of the files may be updated independently of another, then the references break *unless* you very carefully track the original uuid of each block and make sure it's maintained when that data is completely replaced -- or, given the current design, you would have to track the index of the block and maintain that.  The latter is admittedly trickier if you talk about changing the total number of blocks in the file.  If we require that users update array data in-place (i.e. `tree['data'][:] = new_data` rather than `tree['data'] = new_data`) some of those problems go away, but I don't know if it's realistic to require that and the subtle distinction will be lost on most.  There's the additional problem that if the size, striding or data type of the block changes, the reference is bound to break.  The array tag and the block data itself are *very* tightly coupled.

So I'm starting to think that external references to specific blocks is a dangerous and tricky feature.  There are obvious benefits to referencing a single block in an external file (as documented below), but it's less obvious that referencing specific blocks is even needed, so maybe this feature should just be removed.

All that said, I can imagine referencing external *arrays* (as a higher-level concept than a block) by their name within the tree, and that doesn't have any of the issues with indexes vs. uuids etc. raised here.  For example, you could say:

```
data: 
  $ref: !array
    "other_file.finf#reference_data"
```

which would pull in an array from an external file like this:

```
reference_data: !array
  shape: [256, 256]
  dtype: double
```

(All of the above can be based on the JSON referencing standard). That seems much more like the level at which a user would want to reference external data, and allows the external file to be updated in arbitrary ways as long as the path within the tree remains the same.