Why is the question "Is it a bad design for a programming language to allow spaces in identifiers" primarily opinion based?

Question

I was checking the "top questions of week" and I just saw the following question was put on hold with the reason "primarily opinion based":

Is it a bad design for a programming language to allow spaces in identifiers?

This specifically made me thing "hey, this is wrongly flagged" in the sense that there could be technical and usability/good practices reasons that would make allowing spaces a bad idea.

Even though the answers should not be a criteria for the quality of a question, the current answers it has indicates that there are indeed good reasons for a programming language to allow spaces in identifiers.

I understand that good/bad design and good/bad practices are subjective. But subjectivity does not mean "primarily opinion based" or "anything goes". If anything, many software engineering practices are "experienced advice". From the help center:

Some subjective questions are allowed, but “subjective” does not mean “anything goes”. All subjective questions are expected to be constructive. What does that mean? Constructive subjective questions:

• inspire answers that explain “why” and “how”
  • tend to have long, not short, answers
  • have a constructive, fair, and impartial tone
  • invite sharing experiences over opinions
  • insist that opinion be backed up with facts and references
  • are more than just mindless social fun

On the other side, this question was put on hold by members with high reputation. So this is possibly an indication that I do not have a correct understanding of what the subjectivity vs opinion based line is.

---

With all that being said, I ask the following questions:

• Was this question correctly flagged?
• If so, could anyone explain, in the lenses of this question, the reasoning behind and why such questions should not be allowed on the Software Engineering Stack Exchange?

Answer 1

Yes, it's correctly flagged and closed.

I see three major problems with the question:

• There's no way to discern what "bad" means. Design is already a subjective subject. What does it mean for a design of a programming language to be bad? Hard to read? Hard to write? Hard to parse, interpret, or compile? Focusing on all three is not really feasible since what's best (again - also subjective) may also not be the best consideration for writing tools for the language.
• It's not about a problem. There's no context for what the problem actually is and what research has already been done towards possible solutions and why those solutions may not be good for the context.
• It's a pros and cons question, which tends to attract a lot of opinionated answers. It's incredibly difficult to write a comprehensive answer to such questions, and without a comprehensive answer, it's hard for people (the asker or others) to judge an answer on how good it is for solving the problem. Instead, the result is often a lot of answers and it turns into a popularity contest.