I was not aware that there currently were arguments about the use of sentinels in future code. I feel that you are being excessively prescriptive here:

"we should nip it in the bud"

is good advice for gardening, but for programming it just results in a lot of pre-emptive arguments about prescriptive rules that aren't needed.

What makes a sentinel a sentinel is *how it is used*, not what it is. As such, sentinels are just another type of (pseudo-)constant, and the same style guides should apply: in general, they should be in UPPER case, at the top of the module. (But remember the rule about foolish consistency.)

And each sentinel should be reused exactly as often as is appropriate. The same as any other constant.

As for exposing sentinels, the same applies to any part of the implementation. Should we make this a public part of the API or a private implementation detail? That has to be judged on a case-by-case basis. Making a rule or even a guideline that just because something is a sentinel is "should be" public (or private) is precisely the sort of thing I don't want to see. Sentinels should be public when it makes sense to make them public and private when it makes sense to keep them as private implementation details.

The bottom line is, I don't think we need sentinel-specific rules in the style guide. That would be like adding specific rules for "numeric constants", or specific rules for "constants used by decorators".