I think that probably the reason it doesn't work at all for case (1), and kind of works for case (2), is that for case (1) the subsystem name and the directory prefix are not the same, i.e., "iLO" and "hpilo/" where as for case (2) the subsystem name, "input", and the directory prefix are the same. But that may be entirely too simplistic.

For case (1), name given by udevadm is, e.g., hpilo/d0ccb1.
For case (2), name given by udevamd is, e.g., input/event0.

For case (1), basename of DEVPATH given by udevadm is, e.g., hpilo!d0ccb1.
For case (2), basename of DEVPATH given by udevadm is, e.g,, event0.

Lookup by the basename of the DEVPATH does seem to work correctly.

But that is hardly what the documentation says.

"""
 Create new udev device, and fill in information from the sys device and the udev database entry. The device is looked up by the subsystem and name string of the device, like "mem" / "zero", or "block" / "sda".

The initial refcount is 1, and needs to be decremented to release the resources of the udev device. 
"""

Created attachment 1079920 [details]
A small c file containing a slightly better example

Shows that lookup by sysname and subsystem obtained by appropriate libudev calls fails when the sysname should include a "!".

I think that:

<dev> == udev_device_new_from_subystem_sysname(
   context,
   udev_device_get_subsystem(<dev>),
   udev_device_get_sysname(<dev>)
)

should hold true for all devices <dev>, but the attachment above illustrates that in some cases it does not.

What does "using the name given by udevadm" mean?

Comments #5 and #4 give a much improved explanation of what I think is wrong.
So, udevadm could be left out of this entirely.

The output of the reproducer for the failing and for the successful runs are, respectively:

[root@megadeth reproducers]# ./a.out
hpilo/d0ccb0
iLO
[root@megadeth reproducers]# echo $?
4


and

[root@megadeth reproducers]# ./a.out
event0
input
[root@megadeth reproducers]# echo $?
0

=============================================================================

For the record, "the name given by udevadm" means the value prefixed by "N:" for a particular device in the output of "udevadm info --export-db" or similar calls.
Like this:

P: /devices/pci0000:00/0000:00:1c.2/0000:01:00.2/iLO/hpilo!d0ccb0
N: hpilo/d0ccb0
E: DEVNAME=/dev/hpilo/d0ccb0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:01:00.2/iLO/hpilo!d0ccb0
E: MAJOR=244
E: MINOR=0
E: SUBSYSTEM=iLO

or like this:

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0/event0
N: input/event0
E: DEVNAME=/dev/input/event0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0/event0
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=64
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=736349

P is for path and N is for name?

The kernel translates '/' in device names to '!'. libudev translates them back
to '/', but udev_device_new_from_subsystem_sysname() does not doe any
translation. We could add that, I will check.

N: is for the device in /dev, it has no direct connection to sysname in /sys,
they are different for many devices, which is fine.

https://github.com/systemd/systemd/commit/a9ec9f29420623133c419ddc8864921a824751fb

Can you test this using the rpms from http://people.redhat.com/dtardon/systemd/bz1263351-udev-lookup/ ?

I'm afraid I no longer have access to a machine w/ devices in the iLo subsystem,
or w/ any devices that would expose the code defect, AFAICT.

Oh, well... Let's just pretend the problem doesn't exist then.

Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto

It looks like the fix was merged into the master branch in commit a9ec9f29420623133c419ddc8864921a824751fb, in Oct 2015, just a month after I reported it. I'm satisfied with it being fixed now, I don't need it fixed for RHEL 7.2.