Thoughts welcome!
Here are some!
I think ArchiMate's discussion of "generic/specific" is unfortunate. Or just plain wrong. Classifiers should never be used to represent a specific individual.
In UML terms, "generic" and "specific" should be used to denote what generalization/specialization relationships show, and Customer cannot be specialized to "John Smith" -- that's an instantiation if ever I saw one. Customer could be specialized to Private Customer and Corporate Customer, but not to an individual member of the set of all customers. That's instantiation.
Instances are set members, and classes are sets. Specialization creates progressively smaller subsets (and multiple inheritance creates intersections), but even a subset containing only one member is still a set -- it isn't the member. You could specialize Customer all the way down to "Customer Whose Name Is John Smith", but there is still a world of difference between that and the instance "John Smith".
As to Classifier, I think that's a bit of a red herring here. Classifier is a concept in the UML metamodel, not in any actual model created using UML. Throwing metamodel concepts into a regular model doesn't really make sense. It's like if you're reading a novel, and suddenly the author breaks into a definition of the term "adverb."
Classifier is the generalization of most element types that are not instances or structural features -- in other words Class, Component, Interface, Use Case, Actor, Node, Activity, etc. One of the characteristics of a Classifier is that it is instantiable, another is that it can be the source and target of generalizations. Those characteristic are inherited by all specializations of Classifier.
So I would say no, there are no classifiers in your examples. Car is a class, and BMW 318i is another class which is a specialization of Car. The only classifier here is Class itself. If you want to look at the metamodel side, Car and BMW 318i are both instances of Class. You can look at Car and say "this is a Class", but you can't look at it and say "this is a specialization of the concept Class".
It may help to add (silently in your head) the word "characteristics" after the name of any classifier. The Car class defines a car's characteristics, the Customer actor defines a customer's characteristics.
An instance can represent either one (specific) or any (unspecified) member of the set defined by the classifier. Which it is, is up to you the modeller: UML has no concept of definite and indefinite articles. I usually use named instances in the former case, unnamed ones in the latter. Or you can name your instances "a", "some" or "any" if you prefer.
Regarding actors and roles, you raise some interesting points. I disagree with your contention that UML Actors are incorrectly named, because Actors belong to Use Cases where they are loosely defined as those who act, or more specifically those who interact with the system.
Roles are often useful, but you can't replace Actor with Role because in contrast with actor, a role can't be defined simply as "that which (inter)acts." Role must be defined by two characteristics: that which takes on the role and the situation in which the role is taken on. In other words, Role is a relational concept and as such is best represented by a connector.
So in a use case model you could use a set of reusable actors, and stereotype the use case associations with "approves", "supervises", etc to represent the role each actor takes on within the context of each use case.
/Uffe
