Regarding your first question (I also had it), this is what I learned about unix sockets in luasocket:

require 'socket' -- most likely required prior to:
server = assert(require 'socket.unix' ())
assert(server:bind('/path/to/socket'))
assert(server:listen())

And then you use it as usual, except that (most notably) getpeername and getsockname methods are missing in server.

One more thing to note: you have to os.remove('/path/to/socket') after (or before) serving on it, because otherwise bind will fail with "Address already in use". Unlinking socket file before bind and before exit is a practice of FreeBSD syslogd, so it seems legit.

For you second question, LuaSocket 3.0-rc1 doesn't seem to support dgram sockets, but latest (of now) master does. Still unclear whether it actually works, as no docs seem to mention this in grep -rni unix luasocket-master/doc, but this can be assumed from the the sources:

server = require('socket.unix').stream() -- or .tcp() alias
server = require 'socket.unix' () -- the same as above

server = require('socket.unix').dgram() -- or .udp() alias

require 'socket' -- most likely required prior to:

I found that is not needed.
Some of my unix socket client code with error handling on the connect and 10 second timeout:

local socket = assert(require "socket.unix"())
local function connect(path)
	assert(socket:settimeout(10))
	local status,err = pcall(function() assert(socket:connect(path)) end)	
	if status then return true end
	io.stderr:write(err.." ("..path..")\n")
	return false
end

if connect("/path/to/socket") then 
	assert(socket:send("command\n"))
	local reply = assert(socket:receive())
	do_something_with(reply)
	assert(socket:close())
end

I tried using the undocumented socket.unix API as shown in the above comments. It worked for simple cases but later I ran into a lot of difficulties, leading me to think the code is buggy. I recommend using luaposix instead.

Any example of problem you could share with us? Out of curiosity.

My setup is a bit unusual. I'm running a Unix stream socket server in Deno, and making requests to it from the embedded Lua 5.3 in Pandoc. When I ran the Pandoc processes sequentially, it works fine. But starting at -j4 (I'm using a Makefile), the server reliably crashes on an accept(2) call with errno 22, EINVAL:

error: Uncaught (in promise) TypeError: Invalid argument (os error 22)
    at processResponse (deno:core/core.js:223:11)
    at Object.jsonOpAsync (deno:core/core.js:240:12)
    at async Listener.accept (deno:cli/rt/30_net.js:117:19)
    at async Listener.next (deno:cli/rt/30_net.js:124:16)
    at async serveKatex (katex.ts:100:20)
    at async main (katex.ts:196:5)

Deno's Unix socket support is unstable, so at first I thought it was at fault. But when I switched from luasocket to luaposix, the problems went away.

I've spent a bit of time trying to reproduce the problem with a simpler setup, and had no luck. It's possible, even likely at this point, that the bug really is in Deno and some difference between luasocket and luaposix leads to it being revealed/hidden.

Sorry if I came across as harsh on the luasocket project, which I'm sure is great. I commented here mainly because all the top search results for "lua unix sockets" point to using an undocumented API when there are documented alternatives available. But I might have jumped to conclusions thinking that there is a bug.

Not at all. It's just that the unix domain sockets reuse code from inet domain sockets. So if there is a bug, we would be interested in finding.

At any rate, depending on what the client does, the server crashes? And the server is not using LuaSocket. Is that the situation?

Yes, that's the situation.

I've investigated more and believe I've found the problem in Deno, which I've reported in denoland/deno#9051. So looks like there is nothing wrong with luasocket. I'm not sure why switching to luaposix fixed the problem earlier. I think the fact that I'm using Pandoc complicates things, because even now my bug repro (connect + close to crash Deno server) happens with a Lua client but not with the same Lua code in a Pandoc filter (using the same version of Lua).