Hi Paul,
it isn't a bug in the sense of some code going wrong. But that doesn't necessarily mean we're doing the best job we could for the user.
When you imported the original flow, it included a websocket-listener node which is classed as a Configuration Node. This type of node is not draw in the flow itself and contains some configuration shared by nodes in the flow.
When you deleted the flow, I assume you selected the nodes on the workspace and deleted them. As config nodes don't appear on the workspace, this would not have deleted the websocket-listener node. When you reimported the flow, you then got the duplicate config node.
To delete config nodes, you either access them via a node that uses it (edit a websocket node, select the config node in the Path select box, hit the pencil to edit it, hit the delete button), or you need to open the config node sidebar panel (from the drop-down menu, select 'Configuration Nodes...'). You can then double click on any of them to edit/delete.
We need to find a way to make the config nodes more obvious. You may have a completely blank workspace as far as you're concerned, but there could be a number of 'orphaned' config nodes hiding in the background.
More specifically for the websocket-listener node, it shouldn't be creating the actual ws listener on the server if there are no websocket-in/-out nodes configured to use it. This is how, for example, the MQTT config node works - it only connects to the broker if there is a MQTT-in/-out node using it. This is a general pattern that config nodes should follow.
Nick