Mix-ins are a style of object-oriented design, in the sense that inheritance, or composition, or generic functions are styles of object-oriented design. They all have the same purpose: logically related pieces of code are co-located and encapsulated, and independent pieces of behavior are decoupled. Ideally, the components of your system should have low interdependency, and be easy to combine.
The idea of Mix-ins is that an object may have several functional components, like say a printer, a logger, maybe some access controls for user privileges, in addition to the actual class bits. Under a mix-in system, you would write a printer mix-in, a logger mix-in, and an access-control mix-in, and then any of your classes can get that functionality just by including them. Adding this functionality is supposed to be literally as easy as adding a decorator in Python, but in order to do this, they usually need programmatic access to the guts of your class in order to insert themselves. That aspect, allowing mix-ins to make programmatic additions and modifications to a class, are what separates them from other styles of OOP like inheritance and composition (those other styles see this as breaking encapsulation, while mix-ins say the components are still functionally independent).
A traditional (inheritance-based) object system probably won't be able to write these services as independent components without meta-programming, and you usually see mix-in libraries written on top of meta-programming systems (a more limited form is also available via multiple-inheritance). They goal is that they provide one of the more common uses of meta-programming, but in a structured and standardized form, since raw meta-programming (and unrestricted multiple-inheritance) has a reputation for going bonkers pretty quickly. Adding it to a stricter language like C# requires extending the language with a tool, not just writing a library.
Normally you'd be right, but D co-opts what the rest of the world accepts as having a well-defined meaning pertaining to OOP to instead represent its hare-brained meta-programming paradigm.
The idea of Mix-ins is that an object may have several functional components, like say a printer, a logger, maybe some access controls for user privileges, in addition to the actual class bits. Under a mix-in system, you would write a printer mix-in, a logger mix-in, and an access-control mix-in, and then any of your classes can get that functionality just by including them. Adding this functionality is supposed to be literally as easy as adding a decorator in Python, but in order to do this, they usually need programmatic access to the guts of your class in order to insert themselves. That aspect, allowing mix-ins to make programmatic additions and modifications to a class, are what separates them from other styles of OOP like inheritance and composition (those other styles see this as breaking encapsulation, while mix-ins say the components are still functionally independent).
A traditional (inheritance-based) object system probably won't be able to write these services as independent components without meta-programming, and you usually see mix-in libraries written on top of meta-programming systems (a more limited form is also available via multiple-inheritance). They goal is that they provide one of the more common uses of meta-programming, but in a structured and standardized form, since raw meta-programming (and unrestricted multiple-inheritance) has a reputation for going bonkers pretty quickly. Adding it to a stricter language like C# requires extending the language with a tool, not just writing a library.