I think actually this is not the biggest problem. child properties are
dynamic, and it's not a problem IMO if they are created like that.

That they are added in an init function is an indicator that they aren't
really dynamic.

That's true. However, another indicator is that anything that does not have a
struct field is also not really static. :)
So right now, child properties are all "dynamic" in this sense. This could
change when Anthony converts buses to QOM. The bus right now is embedded into
the HBA's struct, is not a pointer. This likely would change when buses are
QOM-ized, but then the bus would indeed be a 100% static child.

I think having a child property that can be NULL could be
reasonable.

I think Anthony convinced me this is not the case (unlike links). Even if buses
and similar objects are changed to pointers because the implementation needs
that, those pointers should never be NULL (or if they can, the child property
should not exist when they are NULL).

What I would like to get to eventually is:
struct ISASerial {
Device parent;
UART _child uart;
ISABus _link *bus;
};
A child should be able to be part of the parent devices memory with its life
cycle bound to the parents life cycle. This is why a child property shouldn't
be nullable.

I don't think being bound to the life cycle (that is, from realize on)
implies anything about being nullable.
For example, imagine two different types of UARTs with a compatible
interface, and you could choose whether to have one or the other on the
board. Maybe you could even use none at all (probably doesn't make a lot
of sense in this example, but I figure it might in other contexts).

What you're describing is what a link<> is. Whenever you want the ability to
make a choice (including the choice of None), a link<> is the type of property
to use.

But too much choice can be a bad thing. In many cases, you just want to have a
child device for the purposes code sharing. An ISA serial device embedding a
UART is a good example of this.

Yes, you could make a UARTInterface and have the ISA serial device expose a
link<UARTInterface> but that's roughly equivalent to having every chip on your
motherboard be connected with a DIP package instead of being soldered on the
board. You could do it, but it would be very expensive and cumbersome.

So even though once the device is realized, the UART is bound to the
life cycle of your ISASerial, you wouldn't want to have the UART type
hard-coded, but leave the user a choice. Would this be modelled as a
link rather than a child?

Yes. I'm not terribly sure how this would work yet. A link and a child
property both acquire references to a device and release a reference to a device
at destruction time.

For a child property, the reference held by the parent is the only reference in
existing. For non-child properties, the 'peripheral' container also holds a
reference (since you want to be able to assign the device somewhere else in the
device model).

I'm not sure tying life cycles for a user created device makes sense. If a user
creates a device, IMO, the user should be the one to destroy the device.