Is your feature request related to a problem? Please describe.
Yes, the properties class is written as a closure and as such it makes it impossible to monkeypatch new code into place that is needed to handle certain plugin requirements.

Describe the solution you'd like
I would like to discuss possible solutions rather than manually modifying the classes JavaScript as I am needing to do now.

Specifically at this point, I would like to be able to replace a valueConvertor on an existing property:
https://github.com/NativeScript/NativeScript/blob/master/nativescript-core/ui/core/properties/properties.ts#L543

However, being able to replace the symbols with pre-generated symbols would also be another possible useful way. (i.e: https://github.com/NativeScript/NativeScript/blob/master/nativescript-core/ui/core/properties/properties.ts#L521)

My current design was actually to re-declare the property and add my own valueConverter ; however by the time I re-declared the property the properties internal symbol's were already used by views and other classes. I can't seem to modify the property class at runtime before a view has created properties and already using it.

So then I attempted to change my new property to use the original symbols; however because of the closures; the symbols in the get/setters are now using the "newly" generated symbols; and not my replaced "original" symbols.

At this point I'm having to manually modify the NativeScript/Core properties class to replace items to make my "replacement" work.

Describe alternatives you've considered

1. Preloading the style classes and replacing the property before the application starts (seems to be impossible, the property seems to be already declared on view, before I can monkey patch it).

2. Adding a function to properties class; to allow me to reset values. So say I want to reset the valueConverter, I would do Property.setValueConverter(myNewValueConverterFunction); -- This would require us to add three or four new functions. Not the cleanest design, but could look like a setter/getter for those properties...

3. (same as background service? #2, but for symbols) The ability to add a setter for all the Symbols; so when I type property.setNative = it would replace the setNative closure value with the new setNative value I passed in.

4. The ability to pass in a setNative symbol as part of the creation of the property; this would allow me to clone all the symbols from the original property and pass them into the "replacement" property; leaving the symbols alone.

5. Replacing the local symbols with global symbols. So then it is just a lookup of the symbol rather than a new symbol for every property even if the property is the same property. (Going to test this in the next version of my changes) - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/for

6. Some method to eliminate it being closures and instead true properties on the class; so I can do propertyBlah.valueConverter = someFunction;

Additional context
I would like to know which would be the best way to extend this class that would be accepted by the NativeScript team in a PR. This isn't a common issue; but it is something their doesn't seem to be a work around for as the properties are defined way before a plugin can modify them.