I don't see any problems that need solving.

My only interest in this is that I tend to think sentinels that are used for missing parameters should be exposed, and this isn't always an obvious consideration when designing an API.

For example, say there's a library that has a function:
open(name, type, [mode])

That is, mode is optional. I realize that in pure Python, I could find out what sentinel value they're using, unless they're playing tricks with args and kwargs. But maybe this is written in C.

Now, say I want to write a wrapper around this, called myopen, and always pass in "foo" for type.

I'd need to use my own sentinel:
_MISSING= object()
def myopen(name, mode=_MISSING)

But, how do I call open? In the past, I've done things like:
if mode is _MISSING:
  return open(name, "foo")
else:
  return open(name, "foo", mode)

That doesn't scale well if there are multiple optional parameters.

In any event, this just seems like a guideline we should be aware of when adding APIs.

Absent any concrete proposals for a "sentinel style guide", I don't think there's anything actionable here. I agree with Steven that it's a case-by-case thing. One size need not fit all.

As to the issue referenced by Victor: I'm not sure what a style guide would bring to the table. I think the issue of whether to use a second sentinel or not could be decided in this file alone, without needed a global decision.