In general you should divide your application into functional packages rather than structural ones. What use is, for example, a business exception ("Order not found" e.g.) in a general exceptions package?
You should have a high cohesion within packages. I'd rather split a single package into several layers than dividing them by their structural/architectural purpose. For example, I believe that the model deserves an own layer with all its necessities. Then, for the specific model, I'd have an application layer with controllers and possibly another exchangeable layer with views, all tied together with well defined interfaces.
Your second option clearly leads to an architecture where many parts of your application will have unecessary and unwanted dependecies. This will limit your flexibility and extensibility options. Just think about it: Whenever you change a single interface in the model package, all packages that use this package need to have an updated dependency as well.
In short, I'd structure a basic application like this:
model (subpackage/assembly, contains the business logic)
application (subpackage/assembly, contains controllers etc)
presentation (subpackage/assembly, contains views etc.)
interfaces (optional, encapsulates well defined interfaces
so the layers can communicate and for Dependency Injection)
The layers can be namespaces of physically distinct. Physical distinction (compiling to different Dlls) really helps to keep your architecture clean, the interfaces part can be a gatekeeper.
Also be aware that the term model can mean different things. Model can refer to business logic (in OOP mostly an object model of your business domain) or to a single "presentation model (at this point I don't refer to Fowler's pattern 100%, but rather to the myriads of MVC variants in general)". While the first one truly belong to the model package, the latter one belongs to the application layer. I like MVC best when the controller just calls the business logic and the persistence layer. Most of the time it doesn't need a separate model.