The current file format for layouts has mostly stayed the same over the years, with some more recent additions (concrete objects) managing to include their data without changing the format.
I would like to propose updating that format to a new version, in order to give more freedom to layout makers, and maybe also make the format more future-proof. For reference, the current format is documented publicly on the LYT format page.

In the current format, after the 12-byte header, we find object blocks, 8 bytes each. I propose the following 16-byte object block instead:

Compared to the current format, we have the following changes:

• Increased resolution for X, Y, Z coordinates, as well as heading
  
• Introduction of object type, which would basically replace the current index byte
  
• Doubled flags size, to fit more data
  
• Repurposing index to serve as index numbers for objects that need those (InSim circles, InSim checkpoints could use those too)
  

Every object would be exactly twice as big as the current format, but let's see what this really means: we have a 12-byte header, and a maximum of 3,000 8-byte objects, so the maximum file size for a layout is 24,012 bytes, or 24kB (let's not get in the kB vs kiB difference here). With my proposed format, we simply double the object data size, and obtain 48,012 bytes, or less than 50kB. With that in mind, I think we can safely increase the object count limit to 6,000 and still keep the maximum layout file size below 100kB.

I mentioned increased resolution for X, Y, Z, and heading, so let's get into that:

• Currently, with shorts for X and Y, we have 16 discrete values per meter, or 6.25cm steps; ints would provide 65,536 values per meter, or about 0.015mm - no more trouble placing objects just the way we want.
  
• Z uses a byte, which translates to 4 values per meter, or 25cm steps; a short would allow for 1,024 values per meter, or just below 1mm steps.
  
• Same story for heading, a byte translates to 256 values for 360 degrees, or about 1.4 degree per step, while using a short would allow roughly 0.005-degree steps.
  

This increased resolution does come with one caveat: it makes it more difficult to align stuff, as very small steps are possible; we would most certainly need a snapping system to help here.

What could the increased flags size allow? Well I will let everyone give their suggestions, but at the very least it could allow storing values per byte, instead of trying to stuff some data on 2 bits, other data on 5 bits, and all of that depending on the object type.
We could also go for variable-size object blocks, by adding a size byte to the object header, thus storing only useful data about each object, at a small fixed cost. This could be used to make customizable signs with a text field, for instance.

Edit: Fixed value for Z steps, it would be about 1mm, not 1cm.

Very good suggestions and well written. I support.