dodexahedron

As for things like what I opened this specific issue for, this is a relatively human-friendly problem to see, recognize, and fix. For example, any time you see two strings...

Another option, I suppose, might be to just not include the `[JsonConverter (typeof (KeyJsonConverter))]` on the Key class. 🤔

That's all the commentary I had to add right this moment. Now to go write a wall of text elsewhere! 😅

Here's another potential option: The Configuration API looks for a type converter from `string`, using [System.ComponentModel.TypeDescriptor.GetConverter](https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.typedescriptor.getconverter) So, if Key were to also have a [TypeConverterAttribute](https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.typeconverterattribute) like `[TypeConverter(typeof(ATypeThatTurnsStringIntoKey))]`, perhaps the parser...

Oops. I lied. One more just occurred to me. This issue would be a great candidate for a "Performance" project, which would also include other similar issues that are aimed...

Side note: This seems to have overlap with #3023 but is from the perspective of a consumer of the library.

> What would you think of renaming this issue to "Ensure compatibility with C.E.M"? I suspect there are other Terminal.Gui classes where a type converter like this would be needed....

Yep. That's the way it's done. It's suuuuuuper-simple. And it also helps enforce a component of good design by separating configuration types from other types, which has plenty of benefits,...

I've been thinking about this, as well. There's a fair bit of reflection that would make it difficult to do, as-is, without, at minimum, use of attributes to exempt some...

Came across this today, which puts a lot of the relevant concepts in a real-world context. https://sentry.engineering/blog/should-you-could-you-aot