This should probably be isinstance(user_or_username, str). It wouldn't make sense to query for username=False.
We could add assert isinstance(user_or_username, (User, AnonymousUser, str)) to handle incorrect callers.

Same issue here.

Most of my comments on the other manager change apply here as well.

Rather than abbreviating, let's keep the naming consistent with what we use in the other managers. I know in this case it's likely to be for line length limits, but you can have the value in Q(field=) wrap to the next line as needed.

We can probably get away with just testing one type, since the manager won't be affected by the model type.
If we wanted to ensure we're testing with each comment type, what we'd want to do is create a mixin class that takes the comment model we'd test with, have all unit tests operate on that model, and then have subclasses for each comment type. But it's probably not worth it, given the logic isn't sensitive to the type of model.
The docstrings can also just be CommentManager instead of worrying about the .objects convention.

Missing a trailing period.

Okay I made some comments about these lines as general guidance, but I think what's ideal here is to not have two places that are building queryset logic.
_query() is already considering quite a lot of options for building up the queryset. It's easy to rationalize what's happening when reading that logic, but harder when we then have to mentally combine those built queries with this block. We should aim to have one and only one block of logic building any query involving access controls.
I'd suggest we figure out what public should be up-front and pass that in above.
_query() should also be responsible already for the user access (anonymous vs. authed vs. superuser). It looks like it's trying to at least, and that'd be the end goal so that any other wrappers around _query() get the right behavior without duplicating this block.

This can be if user.is_anonymous.

Rather than .exclude, we should be able to use .filter and check against True. It's easier to rationalize the logic if we're not having to inverse.

Same comment here. Nicer to work as a filter.

This comment is no longer applicable.

Do we need transform? We should be able to compare the objects directly.

This looks great! The only thing I want to see before this ships is some more extensive pieces of test data. When dealing with queries or access checks specifically, we should register objects that should not be queried, in order to ensure we don't see them in results.
For access-related tests, that means any combination of access controls that should fail should be included. For example, if testing Local Site functionality, we should have objects on the global site and a different Local Site registered, and they shouldn't be in the results.

Ship It!