If those 2 sections are empty, it's ok to be removed, but having some information here is good.

Same as above.

We need to remove this if libusb20_dev_open.3 becomes a standalone man page.

We need to remove this if libusb20_be_device_foreach.3 becomes a standalone man page.

USB access library
.Pq libusb, -lusb

should be libusb20_be_device_foreach ?

This hyphen was for a long abandoned parser that never worked right. It has been remove

We took that out of example(?), style(9), and the licensing guide following what other projects have done.

https://docs.freebsd.org/en/articles/license-guide/

Library section is deprecated

What is a good way to indicate linker requirements?

What is a good way to indicate linker requirements?

Remove this section, and put ".Lb libusb" as the first line in SYNOPSIS. This is documented in mdoc(7).

The copyright line comes before the SPDX line

This needs an introductory sentence. What is this function for? Why does the reader care about it?

The copyright line comes before the SPDX line

This needs an introductory sentence. What does this function do? The introductory sentence needs to explain to the user if they want to continue reading this page, or if they need to look for a different page.

This is the part that appears when you use apropos. These don't get periods. You want them to be short, and each word is a search keyword. The official spec is "one line about what it does".

This is still 7 characters over the ideal:

libusb20_dev_open(3) - open a USB device to retrieve descriptors and initiate transfers

So, it will wrap on standard console. Not a big deal with library manuals because they're so over loaded, but this makes apropos more legible.

This should be in the imperative tone.

https://en.wikipedia.org/wiki/Imperative_mood

For more information, see the FreeBSD Documentation Primer. It is filled with outstanding technical writing information.

Which OS/version are you typing this from?

Whitespace at the end of the line causes a linter complaint.

This section also needs an introductory sentence.

And so on

Include files have a macro

And this section needs to be moved before SEE ALSO. A listing of standard sections and their standardized order are in mdoc(7).

14.3-RELEASE

libthr.3 as example uses obsolete .Li
Several - like mixer.3 - have no dot prefixed instruction.
Some use .Em like init_msg.3

This is awkward. LIBUSB20_SUCCESS is not an error. Looking at ..
find . -name '*.3' -print0 | xargs -0 grep -A 5 '\.Sh ERRORS'
for inspiration.

That explains it. Please update to 15.0. there are a lot of changes in the manual pages compiler and it's documentation since then. For example, the deprecation of Li has been rolled back.

Is this a system call? Calls go in section 2. I think this is a library function, but I'm not familiar with the underlying subject.

The mdoc language reference manual says to use standardized section names if at all possible.

All of these except the last need a space and a comma.

Is this a system call? Calls go in section 2. I think this is a library function, but I'm not familiar with the underlying subject.

This should be outside the list, it is not an item in the list.

@ziaee i see this was actually removed from the example back in October.

Someone asked me to change this to call. Commits are flattened so I can't see when this was so.

It is very much a library.

That's a comment on LIBUSB20_ERROR_NO_DEVICE which was based on other examples I found for ERRORS.
In between a call to libusb20_be_device_foreach and a call to libusb20_dev_open, the device could become unplugged - hence the error and the comment.