Let's use MVC for the sake of argument. A regular monolith has lots of models, lots of controllers, and lots of views. A modular monolith has several collections of models/controllers/views, which might be tightly coupled internally, but the collections as a whole exposes much smaller APIs to each other. You cannot just reach into an implementation detail of distantly related functionality, even if this functionality is "public" in the programming language package visibility sense (i.e. users repository is visible to users controller).
This is basically what's accomplished by publishing a Thrift/Proto/OpenAPI IDL from a collection of packages comprising a network service. The key insight is that the serialization and networking parts of this are superfluous, what you actually wanted was the visibility rules.
A modular monolith has a single executable which runs in different modes, typically depending on environment variables. So you can run three processes in the mode that handles web requests, five processes in the mode that processes events on a queue (e.g. Kafka), etc. Eight processes, running in two different modes, but it's all the same executable. That's the basic idea of a modular monolith.
By "plain monolith" I meant just any kind of monolith.
