Ideas for future revisions of the MSH4 format:

MSH 4.1:

• ability to use 64 bit node and element tags (see #395 (closed)) (done in MSH4.1)
• changes based on user feedback:
  • add min/max vertex/element tags in the section header (this would allow to decide beforehand if a sparse (and slow) storage is necessary) (done in MSH4.1)
  • switch dim and tag in Nodes/Element section to match the api and the Periodic section (done in MSH4.1)
  • store onyly x, y, z for $Entities of dimension 0 (points), instead of xmin, xmax, ymin, ymax, zmin, zmax (done in MSH4.1)

MSH 4.x:

• rework post-processing fields:
  • ability to choose float size (this can be done without changing the format, by using one of the integer tags in the header to provide the float size)
  • separate tags and values to not mix integer and floating point data
  • block structure for $ElementNodeData (by numcomp), so that size is predictable
• rework $GhostElements section to not mix int and size_t
• additional features for high-performance parallel IO, for readers using MPI IO
• compress the binary arrays using zlib?
• store embedded entities in the brep ($Entities)

Not in the format per-se, but related:

• include an option to renumber meshes based on physical definitions, i.e. renumber all the nodes/elements that are needed by physical groups first, followed by all the other nodes/elements? We could use something similar to getAdditionalEntities in the MSH4 code to sort entities. (implemented in Gmsh 4.1.0)