Does multiple inheritance violate OOP?

Question

Programming

If you do not take into account any particular language, but argue in terms of programming,
then what does multiple inheritance look like in the canons of OOP?
Please explain using your painful example - there is a Node class with the next, prev methods and there is a
Task class with its execute. There is also a List class with inserter, Node removeNode.
And now I want to get a class that implements the behavior of both Task and Node. This is fine?
That is, in fact, I want to implement a third class, a collection or, in my case, List, which
will operate with task nodes, but until it becomes a node itself. That is, it
will be the main node for its children, but on a global scale it will be an ordinary leaf.
But since I have all the task sheets, the node itself must also be a task. Here's how it looks
from the OOP side and from the multiple inheritance side ?
In my case, this is not even multiple inheritance, but a multiple implementation of the
INode, ITask and IList interfaces ( IList, this is a very strong word, because there is another interface that provides one set method, in the implementation of which the passed object is inserted into the current this. next = method to be set).
What do you say?
For clarity, a little code...

interface INode {
  next: INode
  prev: INode
}

interface ITask {
  execute(): void;
}

interface ISet {
  insert(target: INode): void;
};

class SomeClass implements INode, ITask, ISet{
  next: INode;
  prev: INode;
  
  execute():void {}
  insert(target: INode):void
  {
    // и здесь просиходит установка таргета
    this.next = target;
    target.prev = this;
  }
}

UPD:1
Thank you all for the detailed answers. Today, continuing to do yesterday, the first thing that came to mind was building a display list. Languages ​​that have a leaf display have concepts such as parent and child. That is, if I am a display list object and other display list objects are nested in me, then they are child. If I am added to exactly the same display list object, then I will become its child, and I will also have a parent. Also, I, like the sheet display object, have methods for adding children to me.
This example is my case! But how is the storage of children and parents implemented?
Do I like a display list object have a display list sheet that
I have a composition relationship with? Or is there also next - prew, etc.?

Answer 1

And now I want to get a class that implements the behavior of both Task and Node. This is fine?

The desire itself is quite normal, but it is still better to separate it, since these objects have completely different tasks.
We read about SOLID, in particular Barbara Liskov's Substitution Principle . So is the single responsibility principle, low coupling and high cohesion. Regarding the implementation of several interfaces - let's say for the composition of two classes everything will be ok, since you will not break the principle of single responsibility, each component will be responsible for its own and everyone will be happy. And the class that will combine two implementations of interfaces will simply proxy calls to the necessary instances.
Multiple inheritance of norms ... only the risk is high that the whole thing will be violated due to it.

Answer 2

Implementation of multiple interfaces - approx.
Multiple inheritance - not ok.
True, everything is relative.