In this case the viewer shows a incorrect or incomplete routing of the signals going to the multiport switch
This is an excellent point, and you are correct that it is a bug. We will fix it in 2.3.1 this week.
Looking at the garbled DiffPlug image, you are absolutely correct that the routing is wrong based on the labels. And that’s what users look at, so you are correct that this is a bug.
But if you look at the routing based only on the port index / position, you’ll see that DiffPlug matches Mathworks exactly. That’s what I mean by “cosmetic”. The correct wires are connected to the correct ports, but the ports have the wrong labels. In an executing model, that would not be a “cosmetic” bug, it would be functional. But because DiffPlug does not attempt to execute a Simulink model, only to show the data, we are able to simplify the parsing in ways that make it much faster to load and compare models. We don’t simulate block behavior - we just display their parameters and connections. We slap labels on ports at the end, but for DiffPlug’s internal purposes they are purely cosmetic.
The Multiport switch block is … a standard block
You are correct. Even if DiffPlug knew nothing at all about the standard Simulink block library, we could still load and display blocks, display all of their parameters, and show how their ports are connected.
The only thing we gain by implementing the block library is that we can label their ports, and show mask images. If we get something wrong in this logic, then we can end up showing extra ports or mislabeling ports - which is misleading and a big problem - but it won’t affect anything besides the labels or showing empty ports.
If you have any feature requests or bug reports similar to this in the future, what is most helpful is a sample model (just copy-paste the block into a new model) or a screenshot of the detail pane at the bottom-left (see below). We were able to easily reproduce the problem you’re seeing, and we’ll have a bugfix release this week.
