Is there a representation for modern programming constructs that are becoming common in modern OOP/hybrid languages like mixins/traits/categories/partial classes ?
Yes and no. Generally, UML allows the usage of multiple inheritance, which allows you to model something like traits. In a sense, traits in Scala are a way to allow multiple inheritance, whilst trying to reduce its negative effect (namely, the diamond inheritance problem).
As for the Yes part of the answer: you can show traits/mixins as normal classes in UML, or even add a corresponding stereotype to them (either make them abstract, or if you want to be more precise define your own profile with a proper trait-stereotype). A class that mixes multiple traits is then visualized as a class that inherits from these traits (via generalization associations).
However, the UML has no proper semantic concept of this inheritance. Other than a vague description that the generalization means that the subclass gets the features from its superclasses, you will not get a clean semantics. In particular, language-specific semantics like Scala's trait linearization are not directly supported in UML.
If you want to make a very precise model of your Scala traits/classes, you would need to define a custom UML profile and assign stereotypes to your generalizations to document their linearization order. However, that's limited as well, because the order may be different for different classes that share some of their traits.
So it depends on what you want to use UML for. If you want to use it as documentation, you may well be able to live with these shortcomings. If you want to use UML models as a base for code generation or some such, then newer language features spell trouble. While the UML offers semantic variation points it is as a whole based on the traditional OO languages and falls short as soon, as you leave these standard feature sets. While traits/mixins still relate closely to classes/objects, and hence, can be visualized with some trade-offs, you'll be even more at a loss, when you try to use UML for non-OO language aspects (think, functional or logic programming).
Inheritance is class centrive. Traits are behaviour centric.
So, traits are an attempt to decouple behaviour so you need not tie two classes together to an upstream parent.
Yes, you could treat traits as a an outcome of multiple inheritance, and tie the behaviour you want to allocate to a small abstract class. But as we know, we are trying to move away from multiple inheritance because of the constraints that come with it.
Indeed, traits are probably the meta concept from where aspects derive.
The point of traits is then you can pepper any class with a trait without grouping those classes under a common parent.
Where aspect oriented differs is that it is generally implementation oriented. That is, how do you spread concerns over classes and their methods, if the semantics of OO languages does not support traits.
This is not different to the problem for so-called design patterns. There is a school of thought that says design patterns, coming from c++ world, were necessary because of semantics missing from c++ as a programming language - including its conceptual model.
A good example is the introduction of reactive functional languages like ELM. In ELM the MVC idiom is integral to the semantics of the language. So, you can natively code MVC in a few lines, where as you need oodles more oo code in c++.
So, look at traits as a design pattern that is solved by aspects. Now that will cause a stir because there will be an argument that aspects have semantics. They do, implementation semantics. Traits have are a higher level design semantic.
So, no there is no semantic for traits in UML. Whether you could accomplish traits using profiles might be an interesting question. Whether adding traits by profile is the same thing as being "in" UML is another interesting question. I would say no to that too. No because if the root theoretic for UML is OO, and traits are not in the root theoretic, then any use of profiles to add traits will be implementation and not design centric with respect to the notation.