[Feature]: Field for data storage on individual macros

[Pmofmalasia]

Describe the Problem

For various reasons, sometimes it would be worthwhile to store data on the macro buttons themselves. A possible use-case would be for tracking macro buttons that are intended to be temporary and removed at a later time - copying the macro would change its ID, and the label could be changed making that unusable as a marker. Currently, this is accomplished in an unsupported manner using the disabled maxWidth property. I have not made extensive use of this method but others have and may have additional use cases for doing so.

The Solution you'd like

Adding an officially supported data storage property on macros instead of using maxWidth.

Considerations:

Should we just change the current maxWidth property into this storage property?
For as long as I've been using MT, this has been disabled (and minWidth doesn't exactly do what it says either, but that's a separate issue) so I don't see any harm in removing the property altogether unless there are plans to revert this. It would break the macros of those currently using the property in my proposed manner, but it's not supported as is anyway so that seems acceptable.

Should this property be editable within the macro editor?
My preference would be for no - at least by default - as in my mind the purpose of the property is to have a secure non-editable portion of the macro button.

Alternatives that you've considered.

No response

Additional Context

No response

[bubblobill]

I see problems with removing the MaxWidth property, precisely because I discovered the hacky use of it for the purpose you are advocating and shared it as a hack. MaxWidth accepts string values and doesn't seem to go through any checks or value verification tests so it does work well as a data recepticle.

Whilst it shouldn't break anything critical and people who use things for unintended purposes deserve what they get, it will break things.

Take it out of the UI - yes
Create specific functions for addressing it - probably worthwhile
Rename/refactor it to resemble the new use-case - fraught with peril, but potentially a good idea

[FullBleed]

I don't use this hack, but I agree that past removing it from the UI it should not be messed with unless it poses some unstated risk.

I do support @Pmofmalasia 's notion that there should be a "supported" method though.