There is one case where YAML is most relevant: reftests. We hand-rolled our text reftest format with the detached read/write implementations that we've been using for a year now:

• good: syntax is way more stable than the actual DisplayItem representation (which is currently directly serialized by capturing as well as saving as RON/JSON).
• bad: read and write fall out of sync, there is a lot of hand-written code in there.

There is something that we could build though, that would be as easy to read/write as the current reftest format and yet much easier to support. Basic idea is to define a number of types for the pure purpose of stable and pretty serialization (so the types are going to derive the serde traits). These types are simplified version of our display item types.

For example, a transform type could be:

enum TransformOp {
  Translate(Vector),
  Rotate(Axis, Angle),
  Scale(Scalar),
}
enum Transform {
  Composite(Vec<TransformOp>),
  Raw(Matrix4),
}

When writing the serialized syntax for these, ability to skip type names is much welcome:

transform: Composite([Translate([1,2,3]), Rotate(X, 25)]),

Arguably, it's not exactly as simple as it is now, so that's a possible downside.

The idea behind this prettified serialization layer is that:

1. It stays stable! When it changes - we should be able to detect it at compile time and adjust all the reftests (that would otherwise straight fail to load).
2. The serialization code is derived automatically, so it's one less thing to worry about.
3. We only need to write conversion to/from this stable formats from our internal DisplayItem things.
4. It's readable/writable and hierarchical(!), unlike the current JSON/RON dumps that are linear.