> Similarly, when I call a function I create a new environment (think, stack frame) for each call which contains values that are distinct from all other calls. I would expect the same to hold for types defined within a function.

Rust types are not runtime objects.

Also just because a function call creates a new environment doesn't mean everything is part of that environment. `static` items are singletons, even if defined within a function (which is a common case when the function should be the only thing directly interacting with the static).

I don't think the analogy to modules is quite right. I think that maps better to:

  fn foo() {struct Cat;}
  fn bar() {struct Cat;}

and foo::Cat != bar::Cat. Whereas the a single function with a local type maps better to:

  mod foo {struct Cat;}
  mod bar {pub use ::foo::Cat;}
  mod baz {pub use ::foo::Cat;}

and bar::Cat does equal baz::Cat.

But maybe I only think that construct maps better because I'm predisposed to the interpetation I described. I do see what your saying, and agree that Rust could work that way; I'm just not convinced it's a bug that it doesn't.

The behavior you describe would be more surprising to me than the existing behavior, but clearly that's not a universal sentiment, and I'm not sure which behavior would be less surprising to most people.

Seems reasonable to me. I was thinking more of closures, which capture their environment, but those are of course a distinct type in Rust.

a stack frame is a runtime object, while a type exists only to the compiler. the suggestion to create it in a call just makes no sense. a type is a definition, not an instance.