Incompatibility of HIGH,LOW, INPUT, OUTPUT

Is this incompatibility of the important instructions like
pinMode(...)
digitalRead(...)
digitalWrite(...)

necessary? NO from my point of view!

For the NANO V3 in ...\Arduino\hardware\arduino\avr\cores\arduino\arduino.h:
#define HIGH 0x1
#define LOW 0x0

#define INPUT 0x0
#define OUTPUT 0x1
#define INPUT_PULLUP 0x2

For the NANO Every in ...\Arduino15\packages\arduino\hardware\mbed\1.1.1\cores\arduino\api\common.h
typedef enum {
LOW = 0,
HIGH = 1,
CHANGE = 2,
FALLING = 3,
RISING = 4,
} PinStatus;

typedef enum {
INPUT = 0x0,
OUTPUT = 0x1,
INPUT_PULLUP = 0x2,
INPUT_PULLDOWN = 0x3,
} PinMode;

The enums are a good idea - but only if it will work for all NANO variants. With such differences is is near impossible to write sketches for these "compatible" processors!
A work-around may be some tricky #define...

If you use the Enums everything should work fine.

Remember that Arduino runs on many different hardware targets e.g. SAM, SAMD, STM32, Teensy3.x, ESP32, ...

If you have a problem, quote which library example fails.
Then it can be fixed. Whether it is in a specific Core or a Third Party Library.

A vague assertion will not get anywhere. An example to show the behaviour means that someone can investigate.

David.

RudolfAtRTC:
For the NANO Every in ...\Arduino15\packages\arduino\hardware\mbed\1.1.1\cores\arduino\api\common.h

You're looking at the wrong core. Nano Every uses the megaAVR core, not the mbed core. However, it's the same system in megaAVR.

It's important to note that this change was made in the ArduinoCore-API project. This is a project to move all the non-architecture specific code to a dedicated repository from which it can be shared between all cores, rather than having the same code duplicated over and over again. The ArduinoCore-API code will eventually be used in all official Arduino cores (and hopefully many 3rd party cores as well), including the Arduino AVR Boards core of the classic Nano. Arduino is just starting on this project by using ArduinoCore-API in all their new cores.

Some breakage has been noted from this change, which I reported to Arduino some time ago:

There is a proposal to fix that issue, but I don't believe it has been implemented in any of the published cores yet.

Tp pert: Thank you, that looks plausible. I will wait for the changes and work-around with some #defines...