Do you have a concrete example of how this would work?

Nope, it's only a recent idea. But say in a Python REPL you do len(0) what happens is this: https://i.imgur.com/wzbKaJ6.png it says, in red:

> len(0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object of type 'int' has no len()

When you try to use a crosshead screwdriver in a slotted screw, it simply doesn't fit. It doesn't also say Traceback: TypeError: object of type 'slot' has no orthogonal drive slot, in red, while pushing your work away from you.

I'm not suggesting hide the error, pretend it's fine, or paper over it with "error but I know you can do better :) :) :)". I'm suggesting a thorough but subtle shift in the approach so it's not you trying to build code and the computer bluntly rejecting it for being imperfect, and then you fight that. Instead it's you and the computer cooperating on the task of making code which works and does what you want.

> len(0)
Line 1: len() received something it cannot process (an 'int').
It is intended for lists and strings, use help(len) for more details.

1) Doesn't emphasise that it's an error. You already know it's an error because it didn't give you a length. Function could have a result with details of what happened, instead of throwing an exception. HTTP has a description of one part of it: "The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy the client's corresponding request.". That's neutral, which is good. It then goes on to say that 4xx codes are client errors, and 400 is "Bad Request". That's not good. Imagine you went into an ice cream shop and asked for blueberry ice cream. Would they say "bad customer!" or "Error: we don't have any", or would they say "we don't have any"?

2) Tries to guide you towards what it is intended for and how to make it work, instead of bluntly telling you it's wrong and leaving the rest up to you. "expected end of statement" is better than "parse error".

3) Isn't red. If everything's important, nothing is. Asking for the length of a number isn't a massive critical emergency, worthy of a star ship Red Alert, it's just a slight adjustment of the kind that is required all the time. Probably a typo, chill out.

4) Better if the experience allowed you to dismiss the error message, and it vanished. Visual Studio Code's ability to insert extra lines next to the code to show you messages, and remove them. Visual Studio's lightbulbs to the left of lines of code and hovering tooltip message boxes are good here. PythonWin lets you edit and delete command output.

In Visual Studio as an example, trying to assign a float literal to an int variable: two red cross icons, the text "1 Error", an error code, a red error underline under the code, a red marker on the scrollbar at that line. OK, okay, I get it. The message is neutral, helpful, "Cannot implicitly convert type 'double' to 'int'. An explicit conversion exists (are you missing a cast?)". Have that message without the confrontational iconography. Tell me "the result of the parser's attempt to understand the code", draw my attention to it, draw an arrow pointing to it, highlight it, do useful things. Don't give me the constant low grade stress, don't give me the same kind of feedback when I mistype a comma as a dot as when something really serious is going wrong.