Assuming anyone else runs into this...

Or maybe it could say Expected Module not {!r}?

There's a warning (just below your change) that says the exact same thing, but also points to the elaborate function in question which I think should be more useful. Does it not fire for you?

Oh. You're right. My fault for not noticing that.

I think I should do something with that warning, if people don't notice it, it's as good as not having it in first place...

Maybe making it yellow?

That's... hard to do in a good way. Think of the people with white terminals where it'll be unreadable.

don't forget, you can change block backgrounds per character.

Right. That will then break on Windows if I use direct escape sequences. And if I want to do it portably it'll be a new dependency and people would complain about that. Colors aren't a good solution.

This is tricky...
I'm honestly surprised that Windows users use nMigen in
Windows-Python native, instead of just using Bash-for-Windows.

Is red not a good color? GCC and clang always seem to
emit red regardless of the color scheme. And honestly...
if you have a red terminal background, you're asking for
trouble...

I'm honestly surprised that Windows users use nMigen in Windows-Python native, instead of just using Bash-for-Windows.

One thing I've learned is that no matter how liberal my assumptions about the downstream environment are, they are always insufficient to cover the workflow of a surprising amount of people. I think every nMigen tutorial that exists describes a completely different installation method, and that's just on Linux!

Also, Windows Store has an official Python package, so if you just type python in cmd (without having anything at all installed) it prompts you to install that. That package actually works pretty well, so I'm happy to have people follow that path.

You can also just ask nMigen users to read errors
more carefully. Something I should do more often
in general, ha

I think I've also seen error messages prefixed with
a sign like ==> error foo on line 1234.

Here is a horrible suggestion (but /might/ work);
(a) Collect all warnings as they are emitted.
(b) On exit, output a summary of the warnings that were emitted (maybe things like the number of each type of warning).
(c) If a traceback / error occurs, make sure to remit the warnings just before the trace back output.

I would generally say that anything which isn't the in the last few lines of output is going to be very easily ignored?

Maybe you could also having a -Werror type thing that is enabled by default and people can turn off if needed?

(c) If a traceback / error occurs, make sure to remit the warnings just before the trace back output.

Just before (i.e. above traceback) or just after (below traceback)?

Just to confirm, I was ignoring what was above traceback
as I assumed it was part of the traceback.

UserWarning was above traceback.

So collecting and going below might be better.