One point ... when you add a table in a 1:1 relationship to an object type that means you're extending the type...
So if you go that route (i.e. not create a person) I'd suggest specializing the general-comment object type as a "unregistered_user_comment" or the like. Note that you end up with exactly the same select queries to grab data but conceptually it's cleaner. Or, if it's not, the object type system is useless :) We should really extend types when that's what we're doing, IMO.
The obvious approach in general-comments, then, would be to create an object of one type or another. I'm assuming that registered users - those logged in at least - have comments posted as they are today.
The query can return the e-mail and similar info with a UNION subselect in the rowset specifier, pulling it either from the person/user table or extended type table. The code would have to guarantee that there's a row in persons/users or the "unregistered_user_comments" type-specific table to guarantee the UNION only returned one row.
I think this would be a really easy feature to add to general-comments.
Two further arguments against the "person" approach:
1. opens a system to a nasty DOS-type attack, if spam is bad just adding comment rows it will be two or three times as hard on the system if a new person is added for each one, and cleaning up afterwards will be at least twice as hard.
2. more code would need to be written - code that needs writing anyway if anyone ever uses "person" - because once you start creating "persons" in the db the user registration code needs to be able to transform them into "users" ...
