Shouldn't DataType represent just the "type" of the data and not data itself? A "larger and smarter object" isn't just a NodeData?

Our use case is that one data type needs to accept different other data types and we want to control this from the model. We cannot use TypeConverters and we have thousands of types and creating converters from all the combinations would be horrendous task and would eat a lot of memory in the register. Besides that we actually do not need to convert any data, we just need to control if the connection can be made or not.
If NodeDataType would be a pointer we could then inherit and override the equals operator to not just compare the ids but to compare lists, or id existence in the acceptance list, e.g. It would allow having more control over connection creating.

If NodeDataType would be a pointer we could then inherit and override the equals operator to not just compare the ids but to compare lists, or id existence in the acceptance list, e.g. It would allow having more control over connection creating.

you can do it the exact same thing with the current NodeDataType implementation.

What do you mean? The NodeConnectionInteraction::canConnect compares IDs of NodeDataType. This is not enough for my use case. I need to override this comparison in my code to make the connections possible. Even if I change NodeEditor to compare structs instead of IDs and add struct comparison functions to NodeEditor I still can't override them in my own code to do smarter comparisons.

If NodeConnectionInteraction::canConnect would use NodeData::sameType method instead of comparing the IDs directly, then I can work with it but I guess this is not wanted.

I think it could be possible to assign "custom" NodeConnectionInteraction to FlowScene by implementing FlowScene::setCustomNodeConnectionInteraction(NodeConnectionIteraction const & nci).

Then we could ask NodeConnectionInteraction const * FlowScene::hasCustomNodeConnectionInteraction().
If the returned pointer is not nullptr we'd use the overridden function canConnect.

Inside you could use some matching table tailored to your application.

QMap<id, id> compatibleTypes.

By doing all this we'd keep the "can connect" behavior encapsulated into one class and do not introduce plenty of complex changes.