That's how my reading of it goes. You provide an "endpoint" for the library to call, configure the Unit framework, and their Manager connects the nginx frontend to that Unit framework.
No real idea if it does so using fcgi or some other socket-based proxying, or if the unit is spun up as a separate process and handed the raw socket and some shared memory after the headers are parsed (closer to how mod_php works).
Yes, you can generally think of it as a replacement for mod_php as Unit would parse requests from NGINX, pass them along to the PHP parser, then return the responses back to NGINX. That's the same job mod_php does for Apache and what PHP-FPM (essentially) does for servers like NGINX.
Upon first reading I thought that Unit needed to be behind NGINX to function. When actually it listens for requests as a separate server, entirely. It only provides an API for configuration purposes.
However, If you want to use the other features of NGINX, like providing static files, you will need to put it in front of Unit.
No real idea if it does so using fcgi or some other socket-based proxying, or if the unit is spun up as a separate process and handed the raw socket and some shared memory after the headers are parsed (closer to how mod_php works).