The most obvious way to store backing fields for arbitrary objects is to have a global concurrent dictionary that stores weak keys, and a compiler-generated class to store the backing fields as the value. But then you have a performance problem of needing to do a lookup from a weak-concurrent-dictionary every time you access any extension backing field.
The higher-performance alternative would be a second shadow variable in code that uses the extension backing fields. Do your dictionary lookup, then cache the backing-fields-object so you don't need to redo lookups for it. But that would be function-local.
If the extension property doesn't need a new backing field, it's trivial, you're just making a new getter and setter function pair.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Edit: include ;-) at the end. Client filtered it out...
IronPython and IronRuby had a lot of potential.
The 2 apps in production are MAUI Blazor Hybrid apps. The learning curve was very small since I already was familiar with C# and Razor syntax after having built many C# server-side rendered web apps. Development is quite rapid since it's essentially using web technologies. For my use cases, the users do not care about the app looking native as these are B2B apps. Both apps are deployed in the 2 major mobile app stores and 1 app is also deployed in the Microsoft Store.
The 3rd app was an internal-only Android app built with the UI written entirely in C# instead of XAML. I chose to write the UI in C# instead of XAML primarily just for fun and to see how that would work out. I ran into a lot more issues using native UI when it came to me wanting to customize things, such as removing an annoying bottom text underline/border that is added by default to Entry (textbox) controls.
I'll probably never build another native UI app if I have the choice and will stick to MAUI Blazor Hybrid apps because it is so much faster to create the app using web technologies (HTML/CSS).