This is not expected, multiple connections for the same device are well supported and tested (I for example have one connection with DHCP and one for connection sharing).

You should have entries for them under "Wired" in the network menu.
Can I see a screenshot?

Created attachment 215274 [details]
network applet with first profile

Created attachment 215275 [details]
network applet with second profile

Created attachment 215276 [details]
Networkmanager (without expected possibility to choose the profile)

I got an tip not to use the networkmanager gnome-shell comes with. Instead I used nm-connection-editor. Now the connections show up in the network manager. 

But as shown in the screens there is an bug displaying the namens. For the 2 screens I switched the profiles and only the active profile is named properly.

On the other side referring the tickets origin intention I would expect the gnome network manager handle the profiles. But there is no possibility.
Whereas there is an dropdown for choosing the wifi connection there is no possibility to choose the wired profile. Its kind of confusing...

The applet nor shows the right namens. Reboot solved this problem. 

So last point the 'missbehaviour' of the gnome internal network manager...

Ok, so essentially there are two bugs here.
The first one is that gnome-shell doesn't react to connection updates and show wrong names until restarted. The second one is that gnome-control-center only offers "Configure..." for the currently active connection.

Since you originally filed this for gnome-shell, I'm leaving this one for the former. Please open another bug for the gnome-control-center product, network component, referencing this one.

Created attachment 215349 [details] [review]
NetworkMenu: fix updating connection lists

Ensure that the UI is updated when a connection changes name or id,
even if it was already known by a device.
Also, use less private properties on NMConnection objects, as they
can become stale and cause problems.

Review of attachment 215349 [details] [review]:

Looks mostly fine.

::: js/ui/status/network.js
@@ +260,3 @@
             let obj = {
                 connection: connections[i],
+                name: connections[i].get_id(),

Why can't it be obj.connection.get_id()? (Or just push the connection object itself)

@@ +378,3 @@
+            this.removeConnection(connection);
+        if (valid)
+            this.addConnection(connection);

So if it exists and it's valid and there's no similar connection, you're going to add and remove it, instead of just updating it? Won't that mess with things?

(In reply to comment #9)
> Review of attachment 215349 [details] [review]:
> 
> Looks mostly fine.
> 
> ::: js/ui/status/network.js
> @@ +260,3 @@
>              let obj = {
>                  connection: connections[i],
> +                name: connections[i].get_id(),
> 
> Why can't it be obj.connection.get_id()? (Or just push the connection object
> itself)

Because I want to compare obj.name, which is guaranteed to be equal to the label in the menu, to connection.get_id() inside checkConnection, to see if something changed.

> @@ +378,3 @@
> +            this.removeConnection(connection);
> +        if (valid)
> +            this.addConnection(connection);
> 
> So if it exists and it's valid and there's no similar connection, you're going
> to add and remove it, instead of just updating it? Won't that mess with things?

Even if I didn't call add/remove, I would still splice the _connections array and call Util.insertSorted on it, then clear the section and queue the UI update.
Calling the existing functions seemed cleaner.

(Btw, addConnection is no longer called from outside, it could just be merged into checkConnection)

(In reply to comment #10)
> (In reply to comment #9)
> > Review of attachment 215349 [details] [review] [details]:
> > 
> > Looks mostly fine.
> > 
> > ::: js/ui/status/network.js
> > @@ +260,3 @@
> >              let obj = {
> >                  connection: connections[i],
> > +                name: connections[i].get_id(),
> > 
> > Why can't it be obj.connection.get_id()? (Or just push the connection object
> > itself)
> 
> Because I want to compare obj.name, which is guaranteed to be equal to the
> label in the menu, to connection.get_id() inside checkConnection, to see if
> something changed.

NetworkManager doesn't provide a notify::id or a id-changed signal? (I guess I don't fully understand the code flow, but a lot of this seems very fancy)

> > @@ +378,3 @@
> > +            this.removeConnection(connection);
> > +        if (valid)
> > +            this.addConnection(connection);
> > 
> > So if it exists and it's valid and there's no similar connection, you're going
> > to add and remove it, instead of just updating it? Won't that mess with things?
> 
> Even if I didn't call add/remove, I would still splice the _connections array
> and call Util.insertSorted on it, then clear the section and queue the UI
> update.
> Calling the existing functions seemed cleaner.

Yeah, OK.

> (Btw, addConnection is no longer called from outside, it could just be merged
> into checkConnection)

No. The separate functions are cleaner.

Review of attachment 215349 [details] [review]:

Sure, then.

There is no notify::id because it's a convenience getter, not a
real property. Also, notify::id on the object actually holding the
property (a #NMSettingsConnection) would have no effect - the object
is just replaced inside the connection.
What we have is a single 'updated' signal, for whatever change has
happened outside.

Attachment 215349 [details] pushed as 35b142f - NetworkMenu: fix updating connection lists

Wow you guys are real fast :) 

Ill gona test it next tuesday at university ;)

And opening an extra ticket for the other issue as adviced.

(In reply to comment #13)
> There is no notify::id because it's a convenience getter, not a
> real property. Also, notify::id on the object actually holding the
> property (a #NMSettingsConnection) would have no effect - the object
> is just replaced inside the connection.
> What we have is a single 'updated' signal, for whatever change has
> happened outside.

OK, so it just sounds like NetworkManager has a bad API. Has there been any thought towards fixing this?