Print metadata: add standard keys like "Overall dimensions", "first layer dimensions", "total filament length/weight"

[vlsi]

It would be great to have a standard set of keys for the metadata.

For instance:

• Overall dimensions. The printer might reject or warn the user in case the printed model will not fit into the print volume
• Dimensions of the "first layer". It might be helpful so the printer could probe the relevant bed surface with a probe. It could reduce the probing time and, it could improve the quality of the bed mesh
• Total filament length for the print. It might be helpful on the info screen before user accepts the print

[gudvinr]

Overall dimensions. The printer might reject or warn the user in case the printed model will not fit into the print volume

Not all printers have rectangular beds. Not all printers even have a volume that can be represented by simple shape.
Since it's not "gcode for cuboid printers only", that will limit applicability or overcomplicate specs.

If you limit "dimensions" to cuboid geometry, that will make models unprintable that otherwise will fit on delta.

Not only that but while "print" might be fitted to the bed, actual moves might be outside of the bed and that could be intended behaviour.
That also creates an issue: how do you determine (on the printer side) whether move is intended to be a part of the model (and thus lead to error) or intended out-of-bounds move (such as tool changes, wipe moves, etc)?

Total filament length for the print. It might be helpful on the info screen before user accepts the print

gcode isn't 3d printer-only file format. Even firmwares that generally used for 3d printers can be used for other things, like CNC or laser cutting.
By introducing hardware-specific entities to specs you are limiting use of the format and/or also creating unnecessary overhead.

Everything you describe have nothing to do with file format. That could be a part of the additional "agreement" on how slicer and printer interact with each other but hard coding options doesn't do any favor for the format nor for its users.