Getting back to this summary:
Windows: {name} and {name}.dll, via %PATH%
OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find()
BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc
Solaris: lib{name}.so via crle, and lib{name}.* via cc
Gnu: lib{name}.* via ldconfig and cc

The "Gnu" selection is what is used for "None of the above", so also for AIX - which generally has neither ldconfig nor cc installed.

Having worked on a patch for AIX so that something that is (aka should) always there (dump) for examining archives for dlopen() openable objects.

In another issue I have had the benefit of lots of feedback from Martin Panter - most of which I agree with.

As this issue is about enhancement my feedback re: AIX behavior of dlopen() is that dlopen() takes LD_LIBRARY_PATH (when LIBPATH is not defined) into account.

In general find_library() is used as: CDLL(find_library("xxx")) - as in I do not care if the result is None or libxxx.so.y.z - just do it. However, if find_library() and CDLL() are written so that they "find" the same library object then it does become possible for a programmer to verify that a supported version is what will be loaded.

The return value from find_library() should be related to it's argument - just as dlopen() would 'react' (better, search *PATH*). If no path element ("./*" | "../*", or "/*") then no path element should be in the return value. The case for using path elements is because find_library() could be used to verity it's existence before calling CDLL() - what I did not know initially, but consider vital for proper behavior is that CDLL(NULL) just returns 'python' itself.

To underline that there are many issues that have been left unaddressed for years (this discussion here is nearly 6 years old) I mention:
"The case of python calling find_library("uuid") - on AIX this is probably NULL, as libuuid.so(.X) is not native to AIX - and even if it is present will not be found via a non-existent ldconfig or cc (only thing the "Gnu" option even considers).

IMHO: find_library should reflect dlopen() - with find_library being, as documented.

From the Python2.6 documentation (when introduced?)
"""The purpose of the find_library() function is to locate a library in a way similar to what the compiler does (on platforms with several versions of a shared library the most recent should be loaded), while the ctypes library loaders act like when a program is run, and call the runtime loader directly.

The ctypes.util module provides a function which can help to determine the library to load.

ctypes.util.find_library(name)
    Try to find a library and return a pathname. name is the library name without any prefix like lib, suffix like .so, .dylib or version number (this is the form used for the posix linker option -l). If no library can be found, returns None.

The exact functionality is system dependent."""

This pre-dates my experience with python, so if I inaccurate in assumptions - correct me, but please be patient with me.

What I miss is a PEP on this topic. From the limited reads of other PEPs I have read I think (rather hope) that inconsistencies in documentation could have been caught.

While (as Martin mentioned earlier in this discussion) find_library() behaves as "build" aka cc/gcc and CDLL follows "run-time" loader. imho, this is inconsistent - and the inconsistency is also in that short bit of documentation:

a) """The purpose of the find_library() function is to locate a library in a way similar to what the compiler does (on platforms with several versions of a shared library the most recent should be loaded) (i.e., always find the latest version)"""

and
b)"""The ctypes.util module provides a function which can help to determine the library to load.""" IMHO: how it is expected to be used because I (i.e., the python programmer) cannot provide additional specification to locate a specific version - find_library() is meant to find the latest always

As the Python3.5.2 documentation is nearly verbatim - this is still the documented condition.

So - I am very happy about Martin's (partial) comment:
maybe changing towards run-time would not be such a problem as I first thought.

CDLL() does a search, by definition. Maybe I do not care what it finds - but the argument to it is expected to platform dependent.
The "remaining" limitation of find_library(), even with searching *PATH* included is that it MUST also return the latest version (as a request for a specific version may not be made, or any other "extension"). An additional weakness is that what it "finds" must always be prefixed by "lib", while dlopen() has not such requirement. (FYI: I ran into these 'unusual' shared libraries while packaging sudo. While it is unlikely that python would ever load these sudo libraries it does show that there can be shared libraries that can accessed by not "found")

Hoping this helps the discussion - would be good to have at least a definition/documentation change so that decisions can be made.