Paul Moore writes:
[S]ubjecting a newcomer to the need to [deal with extra requirements from other participants] right up front isn't exactly fair or helpful.
But avoiding that is what core-mentorship is for. Perhaps we can advertise that list better, and maybe more people can mentor there. But a proposal that comes to Python-Ideas is going to be presumed the object of public discussion for the benefit of Python, not mentorship for the benefit of newcomers (and in the long run for Python). People will have their say, and much of that will be pretty abrupt from this point of view. I don't think it's a good idea to impede discussion.
But people *think* of ideas because they hit a problem of their own. And they come here out of a sense that sharing a possible solution would help the community. It's not very encouraging if they get treated as if they are simply saying "solve my problem for me".
I don't think I've seen that as a matter of general attitude (though I have seen it said explicitly to obnoxiously pushy would-be contributors or people clearly unwilling or unable to do the work themselves, but unwilling to take "maybe" or "later" or "no" for an answer). Definitely, new contributors get asked why their problem is so important it needs to be in the stdlib or language, but they also get help with that ("what are *your* use cases? are there others that you know of? is the three-line implementation easy to get wrong for some reason?" And closest to "solve my problem for me" is "is this the only specification, or would other use cases prefer a different one?")
My feeling is that very few contributors originally come to give to Python what it needs. They're here to give what they need to Python. There's nothing wrong with that. Very often it's a shared need. But as you point out, there are often other requirements, and the bar is higher than many projects. I don't think it's possible to pretend that's not true, outside of mentoring environments.
We probably need to get better at helping such people to polish their ideas, *without* focusing too heavily on their original problem (or worse still, on criticising their original solution of that problem). The original problem is the initial use case for a new feature, of course, but focusing on "how does your original problem generalise, so we can see what common features a solution should have"
In a word, we need to be prepared to mentor every newcomer. Would be nice, but I don't think it's practical.
In fact, I think this thread is one where the discussion went about as you say you would want it to. That is, we fairly quickly focused on the issue of precisely representing all valid JSON (specifically high-precision numbers), it got generalized to __json__ to handle not only Decimal but user-defined types. Then it was pointed out that the generated language will be valid ECMA 434 JSON with no way to specify how to convert back to to the original Python types, so Wes suggested JSON-LD. The general response to that was "nope, nope! out of scope!" (for now, anyway), so the proposal reverted to "implement simplejson's use_decimal API", and now it's pretty much tabled as the OP has decided simplejson is sufficient for his purposes. The main problem was at the very start where we hung up on the red herring of round-tripping JSON, which I agree went on too long, and was in large part extended by Python-Ideas regulars, not the OP.
I guess the main takeway for me is avoiding the red herring. The principle is something pretty straightforward like "find something Python can't do, is doing wrong, or really should provide more performance, in the original issue, and don't discuss how weird the use case is." Even if weird, it's probably simplified and taken out of context. Focus on how it indicates Python can be improved. If there seems to be a TOOWTDI already, describe it and ask if it satisfies the need and if not, why not.
rather than on "why do you think your problem is important enough to need solving in the core language/stdlib" (I exaggerate somewhat, but sadly I suspect not a lot :-() would be a much more welcoming approach.
The question "why is it important enough?", like most of the points you raise, often exposes a genuine point of difference between the patch the Python project needs, and the proposals of many would-be new contributors. I don't see a way to avoid that discussion, because it's the fundamental reason why we insist on finding use cases, and it underlies the rationale for generalization and finding commonalities. Maybe we can find more pleasant ways to ask that question, but I don't think it's fair to the contributor or to the Python-Ideas regulars to do much work without asking it in some variation or other.