I think we've indeed been overconsolidating the NBT thing. A large fraction of recent close/duplicate votes have been exactly pointing to this particular NBT question. It's turning into a black hole for all bedrock command questions.
Yes, many things that are quick and easy to do in java edition due to the existence of NBT are harder to do in bedrock because of its absence. But many of these questions are not, in strict sense, duplicates. Especially when I see multiple cases of such closed questions getting a clever workaround answer later anyway that doesn't involve NBT in the first place, even if it takes 50 commands, 16 tons of redstone, and a massive complicated construction to do.
In all cases; most attributes of in-game objects can be modded anyway. While technical support for modding is off-topic, pointing out which json value to change where in order to modify a monster, item, etc. in some way that NBT exposed in JAVA but no longer in Bedrock would be on-topic, especially since NBT basically is in-memory modding anyway (compared to mods just changing those same JSON parameters on the hard drive).
I've even seen new askers explicitly mention the NBT question: they want to know if some non-NBT solution to their new problem, not mentioned anywhere in the canonical, exists. Yet even those still get flagged as duplicate, even when in some cases the answer turns out to be Yes.
When answering such questions, what about this modus operandi?
There are three cases:
No possible workaround
- If you for-sure know that there's no possible workaround, check if a text describing what the user is trying to do is included within the consolidated question. This is important, since otherwise...
New users searching for the problem via google will not find the consolidated question if it does not contain the problem whose only solution is NBT. Let's say that NBT is required to
let a mob drop a note when killed by a specific player
The consolidated question should contain a list of things where we think NBT is required to be able to do these things, including (hypothetically here, in reality for me I don't know would be my answer)
dropping configurable items
conditionally dropping items
, so there's a clear description in the linked canonical question that what the user is trying to do is not possible, with a link to that part of the canonical question. New users can't comment, give bounties, or easily communicate, so will litter the site with duplicate questions if they can't find the canonical question, or can't find why their specific problem must involve NBT.
Then, and only then, should the question be closed as a duplicate. If it's not immediately obvious to a non-expert player why, a comment should be provided with the necessary logic as to why the use of the missing NBT commands is a necessity. If this logic is too long to fit in a comment, the question should simply be answered with said logic, not closed as a duplicate.
You know the workaround
- If you happen to know a workaround (which tends to be harder to do);
Link to the canonical question as related in describing how NBT would be used to solve in the JAVA version, then conclude with describing your workaround, and the possible caveats or limitations it might involve. It can be as easy as using another command, or as hard as having to write a modpack to get your desired changes implemented.
You don't know the workaround
- If you don't know a workaround, but do know a way of doing it with NBT: the most common case;
Leave a comment stating how in JAVA it can be done easily with NBT, but you don't know the answer for Bedrock, with a link to the canonical question. (So it shows up as linked/related), iff it isn't already pointed out by the asker.
Marking questions as duplicates when your 'duplicate' has a completely different title
Here's several resources on this meta pointing out why being too quick to label things as duplicate can be problematic: