Internal representation isn't the issue. Software can internally represent coordinates any way that's consistent (and so bug-free). The conflict is about inte

Internal representation isn't the issue. Software can internally represent coordinates any way that's consistent (and so bug-free). The conflict is about interfaces, specifically interfaces using unlabeled number pairs, between software and humans, or software and other software. It's unfortunate that anyone would implement software with lat/long inputs/outputs, and think that they have the privilege of defining that order however suits them; what they obviously should do, and should have done, is take a moment to think, "How have people communicated earth coordinates in the past? Are there any standards that might be applicable?" and used that order. Of course, if tradition and standards were bad for some objective reason, that might justify it. But not just because some programmer wants to export their way of dealing with coordinates in x, y coordinate order from a cylindrical projection. That's not sufficient reason to upend tradition and introduce confusion and ambiguity in cases of |longitude| <= 90°.