A real issue against disallowing 0/1 to bool conversion is in the translation code from C/C++ to D.

For example, old C code may have thus macro constant.
#define FALSE 0
#define TRUE 1
#define BOOL  int
void foo(BOOL flag);
foo(FALSE);

Translating the code to D:
enum FALSE = 0;
enum TRUE = 1;
alias BOOL = int;
void foo(BOOL flag);
foo(FALSE);

And then, we can misuse FALSE and TRUE.

void bar(bool flag);
bar(FALSE);   // int argument FALSE(==0) now matches to bool

This is enough realistic case. We already have an actual case in core.sys.windows.windows:

    enum : int
    {
        FALSE = 0,
        TRUE = 1,
    }

And core sys windows.stacktrace:

    if (!dbghelp.SymInitialize(hProcess, generateSearchPath().ptr, TRUE))
        return;
(dbghelp.SymInitialize is a function pointer that defined as
    alias BOOL         function(HANDLE hProcess, PCSTR UserSearchPath, bool fInvadeProcess) SymInitializeFunc;

    struct DbgHelp
    {
        SymInitializeFunc        SymInitialize;
        ...
    }
)

If we change the behavior, we should accept the existing code break.

Kenji Hara