Is `sysfs_notify()` raising POLLPRI/exceptfds a design bug?

According to POSIX poll, it says POLLPRI:

High-priority data may be read without blocking.

It is a special read event, likely to read OOB data, etc.

Now in Linux, if /sys/class/gpio/gpio<N>/value is opened and listened for POLLIN via poll or register in readfds for select, the event is permanent and these function exit continuously without waiting for an actual interrupt. For receiving actual interrupts in user-space, one must register for POLLPRI in poll()/epoll() or exceptfds in select(). In fact, kernel documentation for GPIO sysfs interface explicitly asks for this. If dug deeper, gpiolib eventually raises a sysfs_notify() on the value file which is what translates as POLLPRI in user-space.

My understanding is, from the time of interrupt to the time when user-space read()s, the value of GPIO could've changed. It's not like most GPIO devices are regulated by a clock and synchronized with CPU anyway. So the kernel can only tell user-space that 'something happened' on the GPIO line and may not be able to tell with absolute guarantee that the 'state has now changed and that it's worthy of reading'. So raising POLLPRI without POLLIN seems logical.

So my questions are:

1. Is sysfs_notify() raising POLLPRI without also raising POLLIN a bug in Linux? Author of libev claims it is a design bug, but I cannot find any other document suggesting it is so.
2. Can POLLPRI be independent of POLLIN? POSIX does not explicitly say so, nor have I come across another subsystem doing something like this.