SELECT "projects". FROM "projects" WHERE "projects"."user_id" = 1 AND "projects"."user_id"=5

This expected SQL doesn't really make sense to me. It would be better if your example didn't include selecting twice on the same column (not a join) with an equals clause, as I'd expect that to be removed (it's redundant and would always produce zero results). So the resulting sql makes more sense (replace where clause when new where clause uses same col):

SELECT "projects". FROM "projects" WHERE "projects"."user_id" = 5*

Looking at the github example, they used xx=1 AND xx IN(1,2,3), which makes more sense as it could possibly produce results, and I see why they were doing that.

I realize those two conditions ensure the query will never return results, but the point is to let you combine business conditions at a higher level of abstraction, which may indeed result in zero results. There are many cases where this sort of thing is useful, and it's important that the conditions be cumulative.

Yeah, very strange. I saw your comment so I decided to put mine on github, too.

    https://github.com/losvedir/test_github_thing

I'm going to bed now, so I can't really compare mine to GitHub's to yours right now, but it seems to me that sometimes it's a problem and sometimes not. I dunno...

I can reproduce it reliably by first following a has_many relationship, then adding a scope to that. Adding a where clause (directly or inside of a class method like in Github's example: it's the same thing) is okay. Also the scope must filter on the same column as the foreign key. So this wouldn't cause a problem: `scope :recent, lambda { where("created_at > ?", Time.now.utc - 1.week) }`.