Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.
Nope, it's not. But that's how it is...
As for SELECT * - even if I want to return all columns to the user I still generally build something that does some meta-data inspection and returns a specific column set. For example, our website uses a data retrieval system that does three things:
1) Gets the rows from a particular table
2) Resolves any foreign keys in-line - bringing back descriptions from the foreign table based on the content of the referenced row in a configurable manner
3) Checks for an ownership chain that can be validated (i.e. organisations are linked to purchases are linked to licenses, for example: the proc makes sure that if data is being retrieved on behalf of organisation x, then there is no chance that data can be retrieved that belongs to organisation y).
However, the proc that does that makes views which are then schema bound into the database schema, which makes it really obvious when changing tables that you are going to influence other objects.
I'm rambling. I need to sleep more. 😀