No, this isn't like "how many angels can dance on the head of a pin". There's a somewhat animated debate in the agile community right now on the benefits of having a unit test with multiple asserts. I've written them that way, and I've written them with just one. Each has pros and cons.
With multiple asserts you don't know the true success/fail state of the test. Once one assert fails the test stops, so you don't know if the other asserts would've succeeded or not. This is a big problem. However, forcing a single assert often requires lots of duplicated code and/or refactoring effort. If you're spending all your time refactoring your unit tests, then you're not being nearly as effective as you could be.
Eli Lopian has a good middle ground, I think.
I am in favor developers being guided by:
The Test Should Test Only ONE scenario
This does not mean one assert! it means one scenario.
If we need to assert several items to verify that the scenario works, we should do it in the same test (This is how all mocking frameworks work anyway).
This seems like good common sense to me. Yes, you may have issues with failures not telling you all that you need to know, but you also get unit tests which make the most sense from a code analysis standpoint.