Okay, I see your point. As I thought more about it, I realized that what you said applies very well, but to one scenario out of two and I’ve been thinking of the other scenario. Here are the two scenarios (assuming the developer who set different data types on the properties did it on purpose):
- The value being set fits within the size of both (or more) of the properties. Yes, as you said, the user can set those properties individually and it continues to be a valid use case for merged properties.
- Let’s take into consideration this other scenario where the larger property was supposed to hold a numeric value larger than the smaller property’s size. Of course, in this case a user wouldn’t merge properties in the first place as those were supposed to hold different values, and this is obvious when the user looks at those properties in Step settings. But scenario 2 can occur after scenario 1 which means the properties were merged in the past to address scenario 1 and that’s where the possibility of overlooking the difference in properties’ data types applies. Again, it usually wouldn’t happen, but merging obscures underlying properties to look like it’s just one value compared to working with individual properties directly in the Step. I hope this explains my point.
Like I mentioned previously, if you do have a case where having this capability will significantly simplify setting parameter values, I think despite my concerns it is worthwhile to run it by our development team. Perhaps, it is possible to implement such a capability and add warning or error messages to make the user aware of the differences in data types and prevent pitfalls.