Editor refactor: Where to store per-asset data that is editor only?

I am working on refactoring the editor, and ran in to the question of where to store per-asset data that is only used in the editor.

Currently classes like the Entity have a field of a EntityDesign class which stores the editor only data.
It is then serialized with the asset itself.

There are several issues with this:

• It mixes editor data with runtime data.
• If there are additional classes that the editor needs to store data in for an asset, those would also need to be included in the runtime section (again, mixing editor and runtime bounds)
• It bloats the runtime data.

There are a few pros too:

• Easy to access in the editor, especially for things with more complex structures like Entities where each entity needs its own data.
• All in a simple easy single file.

Options

1. Editordata files

Introduce a .editordata file that is saved along side the asset files much like Unity's .metadata files (but whose purpose would be rather different). These files would not be visible in the asset browser.

Pros:

• Clear separation between runtime and editor data.
• Maintains separation between runtime and editor files.
• More extensible.
  Cons:
• A little harder to get data for complex structures like Entities where you want the data per entity.
• Adds additional files to clutter and need to be messed with, especially when moving files.
• Harder to managed, keeping them in sync and users could manually move, rename, or delete them or the asset file without editing the other.

2. Mirrored editordata files

A slight alternative to 1, instead of saving the .editordata files with the asset files, save them in a new fold that mirrors the assets folder.
So instead of Assets/Prefabs/Entities/MyCube.editordata, you would have EditorDataAssets/Prefabs/Entities/MyCube.editordata

Pros:

• Same as 1
  Cons:
• Same as 1
• More complex to mirror
• harder to manually share files.

3. Same file saving

I haven't looked too much in to this one, so it might not be very feasible but still worth mentioning I think.
The editor data and the runtime data are both serialized as separate blocks in the same file.

Pros:

• Keeps everything in a simple and easy single file.
• Possibly easy to manage the data.
  Cons:
• Blurs the line a little bit between editor and runtime data.
• Bloats the runtime file with editor only data.
• Adds complexity to the serialize.

4. Store in field.

Basically just keep it as it is and store the editor data in the runtime class.
Same pros and cons as already listed.

Conclusion

Those are all the ideas I could come up with. There are pros and cons to all of them, please let me know your thoughts and if you have other ideas.

Start by reviewing the Entity and EntityDesign relationship described in the issue, along with the current asset serialization approach. The issue presents several architectural options but names no files, implementation target, or acceptance criteria; a decision on where editor-only data belongs would be needed before work can be considered done.