BOO-703 is also worth considering for strict mode imo.

Field naming convention doesn't seem to belong in there.

BOO-703 seems to.

I was expecting this about the field naming

On the other hand, it is necessary to have something to guarantee no silent behavior-change wrt conflicts between fields and variables don't you agree?
As far as I see, either we'd do like python and require "self." for field references, either we'd have to add a keyword for explicit variable declaration.
Both options would make enabling strict mode source-breaking and less useful in general (since all existing code would require change)

Since we recommended this naming from the start and that most existing code do follow this rule afaik, don't you think considering "_"-prefix, not much a naming issue but more of a "explicit field reference" is a good compromise?
Of course this rule would apply only to internal field definitions (and ignore uppercased static/final fields).

Hmm another mostly non-breaking option that would not require preferring one 'recommended naming' among others:

In strict-mode, disallow to name a variable the same as a field of the declaring type (or one of its super types)

What do you think of this one?

Partially landed in rev.3172
"strict" option added to booc and nant, only changes default visibility for now (other features to follow)

BOO-703 is in.

BOO-1132 is in.

I would definitely like a warning for implicit downcasts and implicit return values, but at the same time I strongly prefer inferred return types and default-public access for methods.

Rationale: implicit downcasts and implicit null return values let you shoot yourself in the foot, whereas return type inference and default-public access are low-risk, oft-used features that are essential to boo's wrist-friendliness. I can see how changing return types affects binary compatibility, but I submit that most developers only need binary compatibility guarantees in a small subset of the code they write.

Shouldn't this feature be more fine-grained?

I would definitely like a warning for implicit downcasts and implicit return values, but at the same time I strongly prefer inferred return types and default-public access for methods.

The warning about inferred return types and parameters types is for API (ie. visible) methods only, by default you do not get this warning since by default all methods are private.
The rationale about this is that as one should try to pick and publicize only methods that are meant to be used from outside, be easier to document to both team and third-party, and more importantly these methods must not change 'without notice' (like it can with slight changes with inference) since it breaks binary-compatibility.

only need binary compatibility guarantees in a small subset of the code they write.

I agree on the large idea (small subset need guarantee) but I disagree with your conclusion, if default method access is public then you probably publish without noticing an unwanted API that is far larger than the "small subset" you intend(ed) to guarantee.
Also since indeed you generally publicize a small subset only, it makes the 'non-wristfriendliness' to add 'public' to intended public methods and their types less of a burden.

Shouldn't this feature be more fine-grained?

It can
Just use:

with booc:

-nowarn:BCW0024 -define:DEFAULT_METHOD_VISIBILITY=public

with nant:

<booc ....strict="true" define="DEFAULT_METHOD_VISIBILITY=public">
<nowarn>
     <include>BCW0024</include>
</nowarn>

or in code:

import Boo.Lang.Compiler
macro compilerSettings:
     Parameters.DisableWarning("BCW0024")
     Parameters.DefaultMethodVisibility = TypeMemberModifiers.Public

Alternatively, if strict mode is too strict for your taste, you can just enable BCW0023 (implicit return statement) since it seems that is the only thing that you care about.