This might already exist (and might even exist within OOP in the form of interfaces), so bear with me:

(If by some exceedingly rare chance this idea is implemented, feel free to use terminology less dependent on American spelling than “behavio(u)r”. In reality, if it is adopted, it will probably be at the suggestion of someone more prominent who happened to have the same idea at a different time, so I don’t even know why I bother to post my ideas).

It seems that we should be more concerned with what an object does than what it is, as we are with OOP. Therefore, it seems to make more sense that we should specify behaviors rather than objects and grant variables specific sets of behaviors, or capabilities. An example of this sort of design (and the one that inspired this idea) is the STL. For example, using OOP, if we have three variables, representing a bicycle, a car, and a person, we can declare them to inherit from class MovableObject, which would have variables such as position and velocity. However, this generalizes a little too much, and now we suddenly need to inherit from some other class (or define person as a base class) to include things like name and eye color. What if we instead designed behaviors such as “go” that could be modularly added to bicycles, cars, and people (or whatever else; we could add it to bananas if they had the appropriate variables)? What if we could attach and detach these behaviors from individual variables to include within-class variation? For example, suppose Mary is a person but is paralyzed and can’t move on her own. We could simply remove the “go” behavior from Mary to represent this fact without having to make a statement about all people in general.

This alone isn’t enough, however. We need to provide goals, else the program won’t have much of a purpose. Say we want to design a program that will make a chicken cross the road:

//How do we cross the road? Execute go, passing all of the to “requirements” as arguments to the behavior and optionally specifying additional ones.
to crossRoad() execute behavior go(OtherSide, additionalArgs1, …);
to crossRoad() execute behavior walk(OtherSide, additionalArgs1, …); //Or walk, which is the same thing, really.
to crossRoadTwice() { crossRoad(); crossRoad(); } //etc.

//It only makes sense for things with positions of type Point to “go”.
//Note that we don’t need to know whether the object in question is a person, car, banana, whatever…

//”Requires Point position” can also be valid, and would cause the behavior to return false (and thus the goal to fail) if executed on an object that doesn’t have a point. “Provides Point position” will actually add a position attribute to the object if one doesn’t already exist. (If one exists by a different type, it’s an error).
bool behavior go(Point where) provides (Point position) {
position = where;
return true;
}

class Chicken {
hasBehavior go; //Chickens can “go”.
//Point position is implied.
…
}

int main() {
Chicken c;
c.tryTo(crossRoad()); //true.
}

If we wanted something more traditional, we could statically define class properties and “require” instead of “provide” them on the behavior. This essentially allows a more object-oriented approach, such as the taxonomic one practiced today. Conversely, we can also modify behaviors (and thus provided but not required structure) at runtime on individual instances. For example, let’s see how Mary would work:

class Person {
hasBehavior(walk);

…
}

int main() {
Person Mary;
Mary.removeBehavior(walk); //Mary can’t walk.
Mary.tryTo(crossRoad()); //false – Mary has no way of crossing the road, since she can’t walk.
}

This can be extended, too. We can add Prolog-style rules, for example, or couple “requires” with interfaces or type checking, and that’s just scratching the surface of the possibilities.

Now that I’ve written this long thing up, feel free to ignore it.