Node access shouldn't add a generic view grant based on the anonymous users

This sounds like a great idea though giving it a try I had no luck with either. Nodes are showing in search even when they grant denys them when reaching that page.

I could be doing something wrong or have some weird setup, though do think this solution is a good one. So I'll keep trying.

Ok this worked well had another issue where the search api access table wasn't getting created. After that was fixed (by just removing the filter and adding it again). This worked!

Here's re-roll with a performance fix which repurposes that static for the implements check to prevent that check on every item which should be much faster.

Typo, :s/impelments/implements/.

Here's re-roll with a performance fix which repurposes that static for the implements check to prevent that check on every item which should be much faster.

Well, probably not much. For one, module_implements() is already statically cached. But more importantly, this method will usually only be called once per page request, so the static cache won't do anything most of the time. Incidentally, I don't know why it's currently there for $account, but it's not very useful and only complicates the code (and probably makes it slower rather than faster 99% of the time).
I'd additionally just cast the return value to boolean instead of counting – we only need the information whether there are entries, not the specific number (even though the performance difference will be negligible here, too – the code becomes a bit clearer).

Also, correct me if I'm wrong but this looks like it would just grant node_access__all to all nodes if there are no implementations of hook_node_grants(), even unpublished ones. This probably isn't a problem currently, but might clash with #1617794: Make "Node access" compatible with additional contrib modules later.

Come to think of it, we should probably merge these two issues to solve (and, more importantly, test) node access issues all at once. Could you please post your patch over there, for merging with the existing one?
There was also a third issue, #2269163: Node access information is indexed in a wrong way, trying to fix exactly the same problem as this one. Maybe the approach there is better suited? It would add node_access__all for all nodes that don't have any other grants assigned (even if there are implementations of hook_node_grants()) – is that the correct behavior, or should access be denied in such cases? The other approach would also take care of modules using hook_node_grants_alter() to add their node grants, I guess.

@drunken monkey, you could be right about node_access__all, thought I've not tested that bit yet. I'm pretty sure they take care of access to published nodes... though yes it needs to be tested.

It does work great with my node_grants from nodeaccess module and my custom ones!

Thanks for the tips on the static, didn't know it wasn't being called on the same request.

Yeah count() is a bit silly, boolean sounds better and faster, I stole that from #1

@drunken monkey I unpublished a node and it dropped from my search api index views results. I think the view itself is dealing with the published state can that be correct for search pages too?

Here are the suggestions you made from #6

that other issue I cross post this patch is doing some un-related bits it seems. I'd prefer to keep them separate so that's why I posted here again. If they start crossing turf more maybe we can merge.

@drunken monkey I unpublished a node and it dropped from my search api index views results. I think the view itself is dealing with the published state can that be correct for search pages too?

It would only do that if you have an explicit filter on "Published". But that's of course possible, yes – though not as flexible, as it won't display unpublished nodes to administrators or others which should be able to view it.

Anyways, I'm closing this for now as a duplicate. I know that the two issues aren't working on the same problem in detail, but they both want to make node access more flexible and compatible with different scenarios and contrib modules. And since node access is really important to get right and not to break in unforeseen ways, I'd really like to deal with all of that in one patch (preferably with a common concept instead of separate additions here and there), get several testers with diverse scenarios for that and only then commit. I wouldn't want to commit a patch to the node access functionality which has only a single tester.