I agree that bugs should never be allowed to discourage the provision of features.

BUT

If you mean you would prefer "select *" when executed as part of a view to be recompiled if need be to fit the current schema definition, then I can understand your point of view, but it would be better for the view definition to be updated automatically as part of the schema change since (especially if schema changes are rare) checking at execute time is not a viable option - it costs too much.

If on the other hand you mean that a schema bound view which is invalidated solely because of a * in the select list shouldn't be invalidated but should be rebuilt as part of the schema change that would otherwise have invalidated it then there's no performance penalty on use of the view I don't believe you can suggest a case where it's workable, in fact I believe that no view such that redefining * to fit the current schema version will never render the view useless no matter what the schema change is can ever exist.

So I don't think the current implementation is a bug: it's the only rational way of handling schema changes for views (allowing views in the same database as the subject tables without schemabinding might be considered a design error, though; I don't think it is, but when I see a view without schemabinding I tend to suspect sloppy thinking, because it's very hard to dream up situations where leaving schemabinding out makes sense - certainly I've never managed to find a case where all the tables are in the database which contains the view).