TL;DR a package is a directory of .odin files which can all see each other. A package is a library and not a way to taxonomize your code.
The main point is that all files within a directory can see each other without needing to explicitly import any. This solves a lot problems from other languages where this is not trivially possible, nor easy to maintain.
Not allowing circular dependencies is a MASSIVE feature. The point is that Odin is trying to have a well defined concept of what a library is, and that’s what packages are: a library.
An “import cycle” means whatever that full cycle is, is the full library. And thus it is now not well defined anymore concept in the language itself.
The other issue is that many programmers like to taxonomize their code thinking that they are “organizing” it when in reality it is just another thing to manage on top of the code itself. With Odin, I have explicitly tried to make things as flat as possible and minimize the possibility of artificial taxonomies and artificial hierarchies. Hierarchies will naturally arise within a program; there is no need to add one artificially.
In Odin, I also wanted a single concept of a what a package was rather than multiple. With your description of C#, that sounds like it has at least 3 ways of describing what a “package” is, which means it does not have a well defined concept of what a package is.
Defining metadata in an external file is not something I wanted BY DEFAULT. This might be necessary writing things like the dependencies and versions of a package, but not to just start working on a package.
As for your last point, you might argue it is “infinitely easier to reorganize files/directories (for refactors) without worrying about how the file will be referenced”, but that is begging the question in the first place. If you keep everything flat, then you don’t need to worry about how things are referenced hierarchically because there isn’t one in the first place.