Have you locked the configuration for usb0 to the actual usb0 device using the "MAC address" field in the connection editor for that connection?  Unless that field is filled in with the device's MAC address, the connection can be applied to any wired device.

So the usb0 connection which ends in an ipaq cradle could have any ipaq inserted.
And thus changing the hardware address.
Same for usb1.

eth0 ifcg DOES have a hardware address. Why not use it?
Why do the ifcfg devices have names?
why do the devices have names?
To use other devices' ifcfg files?

so:
link is down
link comes up
link needs to be configured
get device name to that link
find device ifcfg file with same name in it
verify hw address if present
use ip-info

any reasons to do it a different way?
please explain.

Device names are not stable, which is why they aren't used.  Especially with USB, but also with PCI.  Udev attempts to create stable device names, but it does so using MAC addresses.

Note that with udev persistent network device naming, if you insert a different iPaq into your cradle, you'll get a different network device.  It won't be usb0 because udev will rename the device since it has a different MAC address.  So thus the scheme you suggest will break down.

WRT using MAC-locked connections first, that's a possibility, but that has to be weighed against the priority mechanism that's currently used, since it would change behavior.  An alternative is to have a never-apply-to-this-MAC option for each connection where you could enter your eth0 MAC and thus would ensure that the "Auto usb0" connection was never used for eth0.  But that has the same basic problem.

That is the reason you assign usb0's IP to eth0 when eth0 has a MAC and usb0 hasn't?
Eth0 has all the info you need yet you assign the wrong IP.
Please fix.

And stable device names; that is out of your scope. udev is not networkmanager. Please work with what you get.

1) names plus mac
2) names
3) gamble

The connection defined for usb0 is applied to eth0 because it was the "last used", which is how priority is determined.  If you MAC-lock usb0 to your device's MAC, then it won't get applied to eth0.

Without a MAC address to lock the configuration information too, there is no way to definitively know that the configuration is supposed to be applied to any specific device, since device names are not stable.

Again, if you plug a different iPaq into the cradle, you'll get usb1, not usb0.  So if you lock "Auto usb0" to your iPaq's MAC, your problem is solved.  Using a device name here doesnt' solve the problem at all.

You must agree that this is a broken by design functionality that makes NetworkManager work worse than running the ifcfg-ethX scripts manually.

I explained that there is enough info to solve the issue yet you don't even bother to think about it.
We have a device name (eth0) AND a hardware address in ifcfg-eth0.
So you can plug that info to eth0. And NOT something else.

Why should 'last used' matter when MAC-addresses are so dear, aside from the logical to choose device names (udev does that, not you).
This is a bug. This is last century's functionality so please fix.

Also see https://bugzilla.redhat.com/show_bug.cgi?id=586427 for interesting discussion relating to this bug.

I disagree that this functionality is broken by design.  Assign a stable MAC address to your device using udev rules and a combination of USB serial number or other USB descriptor attributes.

As I state in the other bug, any scheme based on device names breaks down horribly when you plug more than one USB ethernet device into the machine, since USB enumeration is not stable and the devices may well switch names.

If you do as suggested and lock the connections to the MAC address of the device that you'd like them to be exclusively for, then everything works as expected, and the configurations don't get switched.

You can disagree.
It still is borken.
Ot still shows congfusing info.
If not to say 'WRONG" info.

If that is by design, so it is.

Udev is the solution. Not working around it in NM.
Agree with assigning all three bugs to udev?
Then you can explain what needs changing there.

Nothing needs changing in udev; there will always be cases where people won't  necessarily need stable devices names, or where stable device names simply cannot be constructed.  The problem is that unless *every* device gets a stable device name, we cannot depend on device names, and not all people want udev to assign them 'wlan56' for example.  Plus, if you clear out your stable device  name rules for some reason, you lose the stable device names.

Instead, the solution is to tell NetworkManager the same piece of information; the actual unique identifier of the device itself.  We may in the future allow use of other udev-assigned IDs for unmanaging devices, but it's certainly not going to be done by device names for the reasons I describe above.

NM can not be told to not fiddle with usb0.
NM does not facilitate usb0 with a changing HW address.
I.e.: I cannot specify a HW address.
I cannot tell NM to leave usb0 alone.
So what does that leave us with?
A buggy NM experience.
A frustrated user.
Resulting in another NM uninstall.
Yes, that happens when NM programmers do not allow a usb connected Linux device to work with another Linux device.
Yes, this bug is still current in F16.

PS: your udev observations are false.