While not quite the same thing, this is sort of why HTML turned into the disaster it is. Browsers tolerated bad markup and next thing you knew, browser A couldn't render the same way Browser B did (yes there's other reasons, but this was one of the top few, esp around 10 years ago before some of the looseness rules became convention).
As Eric Lippert infers, many of these things are best handled by the IDE, not the compiler. That let's you see what the automatic bits are attempting to screw up for you.
The strategy I think that is predominant now is continual language refinement instead of loosening up the compiler: If it truly is something that the compiler can figure out automatically, then introduce a well defined language construct around it.
The immediate example that comes to mind is auto-properties in C# (not the only language that has something similar): Given that the majority of getters/setters in any app are really just wrappers around a field, just allow the developer to indicate their intent and let the compiler inject the rest.
Which then gets me to thinking: Most C style languages already do this to some extent. For things that can be figured out automatically, just refine the syntax:
if (true == x)
{
dothis();
}
else
{
dothat();
}
Can be reduced to:
if (true == x)
dothis();
else
dothat();
In the end, I think it comes down to this: The trend is that you don't make the compiler "smarter" or "looser". It's the language that is made smarter or looser.
Besides, too much "help" can be dangerous, such as the classic "if" bug:
if (true == x)
if (true == y)
dothis();
else
dothat();