@videlais I was addressing the implication that SugarCube was doing something odd in the specified case, rather than the issue being firmly in Twine 2’s court.
As far as documenting links goes. I’m not opposed to it, but I’m unsure that it’s going to accomplish much. Twine 2 is unlikely to add more core support for square bracketed link markup than it already has and that’s not really the issue here anyway.
Even in the event that Twine 2 offered the API I mentioned previously, the case that started the thread would still be a failure point because there’s likely no way to know the value of the variable, thus the passage name, within the editor. We’re talking run time versus compile time information. The best case scenario here would be for the (nonexistent) API to tell Twine 2 something like: this link’s passage name is only determined at run time, so either do not automatically create a passage or ask the author for its name.