Is this intended to be something like a "last modified date" of this file?

I'd say more like a "last time listed topics have been reviewed".

modified we can do with git history, but knowing when was the last time someone took the time to go through the listed topics and checked their latest status would be good to know.

for example in case nothing about the topics changed, the version should stay the same, but we'd still like to note that we have looked at the list.

if you agree I'd add a comment above the field.

I think it may be possible to have there be a priority listed.
However -- I think it's important to be clear on how such a field is populated.

I would like to discuss this in a meeting on how to capture this.

as discussed, we would likely keep it in for now, but will try to clarify what "high" means in this list and in regard to rustc.

Ferrocene modifications to rustc retain the upstream license

as discussed, we might need to split the license field into source-license and product-license, because even though the Ferrocene source is Apache 2.0 & MIT, to get the docs for Ferrocene to be qualified, you'll need to pay so "commercial".

but I don't like this split of the license field, because it only really makes sense for commercial products.

maybe we make the license field accept either String or an object?
e.g.

license: "Apache 2.0"

license:
  - source: "Apache 2.0"
  - product: "commercial"

or we have license and cost and tools could either be

• cost: "free"
• cost: "commercial"

maybe we make the license field accept either String or an object

looks like an improvement

product might be a bit confusing, because it somewhat overlaps with source.

maybe we name the field qual-kit, meaning qualification kit.
because commonly that is what customers must pay for even if the source is open source licensed and publicly available

thinking further on this, and inspired by your comment, I think we should leave license as plain text, and we can add an optional field, example

# Ferrocene entry
license: "Apache 2.0 & MIT"
additional-details: binaries and support available with a monthly/yearly subscription, and qualification kit available for an additional fee

we can also leave "additional-details" off for now, to avoid slowing forward movement of this pr

would keep description basic to avoid marketing speak (and this applies to descriptions of the other toolchains)

I think one or two short sentences as description is fine.
Otherwise, this field becomes quite useless, because the type is already compiler.

This list will be the base for the website and having a short paragraph per tool as description probably looks quite good.

I think a bit of marketing speak in this field is ok.

if we allow a bit of marketing...

# Ferrocene entry
description: "Rust compiler toolchain developed in the open"

that is for 2 reaons

• it being open source is already shown in the license field
  as sidenote, you can develop in private and only make your software to paying customers while retaining an open source license
• it being suitable for mission-critical use is not relevant to the safety-critical domain

if we avoid the marketing part, we could maybe mention qualified targets (which will easily get stale), or some other thing about Ferrocene... not sure what