I'm stuck: I can't envision a scenario where you would end up with two spatial columns in one table that makes any sense. I'm shocked that ESRI even allows there to be more than one shape column in a table.
Example. One row with original geometry, a second with generalized geometry. You show now scale dependent the best geometry. You prevent data redundancy or the fact to define materialized views. There are solutions but it could be easier.
Your generalized geometry is only appropriate in a narrow range of scales, so you have an entire redundant column just for those scales. At every other scale, you are going to use the original geometry, so why the extra storage?
Plus, you've opened up the issue of users using the wrong column, and then they think the data is of poor quality and not reliable. I have this issue all the time with older datasets where someone added an area field and manually calculated the areas for the features. Now that it is in a geodatabase (with an area field), I still have users who want to use the old area field even though no one has maintained it (and before anyone asks why I don't remove it, I'm not the data owner, so I'm not allowed).
On top of that, you've now opened up the issue that every geoprocessing tool, Select by Location, etc., will have to ask which column should it use for the geometry it need to run for every single input that accept a feature.
I understand that you do not agree. I did my thought on our situation. There are ways to prevent this situation. We now and use them. Sorry to touch a sore spot. That's my last contribution to this idea.
A few other scenarios where we might have multiple geometry columns in a database table or view (not necessarily registered with a geodatabase):
Multiple geometry columns are perfectly valid in Oracle's SDO_GEOMETRY spatial type.
Have a polyline or polygon column as the main geometry column. And a midpoint/centerpoint/startpoint/endpoint as a supporting geometry column.
Yes, XY numeric columns could be used as an alternative. And XY event layers are fast. But there are cases when we need a true geometry column; generating a geometry column from XY on-the-fly using spatial SQL database functions can be slow. Storing the geometry in a geometry column in a table is faster.
Have a SDE.ST_GEOMETRY as the main geometry column. And an SDO_GEOMETRY as a supporting column.
We use ST_GEOMETRY as the main column because all other FCs we use are ST_GEOMETRY. We wouldn't want to try to do spatial queries between different spatial types. So ST_GEOMETRY makes sense as the main geometry column.
