Well, it is the same thing in the sense that you are specifying square properties.
Technically, neither one is specifying square properties. Specifying square properties was the first thing I proposed, but you didn't want to do that. So I proposed an alternative to specifying square properties that would still allow each piece in this game to be described in a simple, self-contained way.
Which can be that the piece reaching it will change its move permanently (true promotion) or only for as long as it is there (location-dependent moving).
As far as I understand what you are proposing, it is neither simple nor self-contained. Instead of giving each piece a simple, self-contained definition, you would split the definition of each piece into multiple interrelated piece definitions that refer back to each other. If they all referred to the same FEN-like string, then they would all require something external to themselves to be complete. If they kept things internalized by duplicating this string, it would bloat the code.
Technically, neither one is specifying square properties. Specifying square properties was the first thing I proposed, but you didn't want to do that. So I proposed an alternative to specifying square properties that would still allow each piece in this game to be described in a simple, self-contained way.
As far as I understand what you are proposing, it is neither simple nor self-contained. Instead of giving each piece a simple, self-contained definition, you would split the definition of each piece into multiple interrelated piece definitions that refer back to each other. If they all referred to the same FEN-like string, then they would all require something external to themselves to be complete. If they kept things internalized by duplicating this string, it would bloat the code.