I think generally this is fine. Maybe I can explain why kfactory is doing this.

If your info (and to some degree settings) are kayout serializable types (mainly shapes, this theoretically includes some potentially interesting types such as a full lyp datastructure, therefore enabling saving the lyp within the gds/oas), you can save your layout (or even pdk) and completely restore a (static) state. Meaning if your pdk only contains static cells, you can package it as a gds.

This comes in extremely handy when you want to load for example special cells from the fab or old designs. They still have all the info and even paramters accessible.

But yes, if info should be fully dynamic, we can rename the attribute in kfactory and with that avoid having to have separate types for info.metadata vs the rest of info.

Thanks for the explanation, the info constraint makes a lot more sense in the context of storing the full state within the GDS file.

Technically we can add extra attributes directly to the Component object for things like test_info or schematic but I think the way we've been doing it where Info is a catch-all for whatever is preferable. I would want to just modify the Info model on the gdsfactory side to add the metadata field and just constrain that field to be klayout-serializable.

Maybe it would make sense to have there be a Metadata model where we put all the metadata intended to be written to the GDS and let Info be fully user-customizable?

KFactory can now read any dict/tuple/list if they contain built-ins (int/float/bool/None) or KLayout shapes (and theoretically other serializable objects.

I would still caution against storing test manifest or similar in there. There is a max size and if that one is exceeded, kfactory/klayout will crash ugly on write (core dump)