In the light of even, say:

#define lowByte(w) ((uint8_t) ((w) & 0xff))
#define highByte(w) ((uint8_t) ((w) >>; 8))

using uint8_t, I find it all rather inconsistent to begin with. Also, while C++ (at least when I read the specs a long time ago, LOL) was based on type-name, not type-structure, if you like to convince me please explain the difference that it makes, when all the while

typedef uint8_t byte;

lets the compiler cast and then link just fine. My reckoning in this is to get rid of "byte" as much as possible - rationale (byte is used as object ident) was given above.
As a compromise, we could leave Arduino.h as it is ...

By the way, I messed up, doing the ESP32 in kind of at the same time, and didn't fix the return type inconsistency here in ESP8266 Core. I have done that now (fixup and rebase).

There are other indications that this discussion is moot, like (AVR Arduino.h to ESP8266's):

-typedef unsigned int word;
+typedef uint16_t word;

and the AVR Arduino.h and ESP8266 Arduino.h are not really very much alike anymore overall. So keep things straight and simple, let's adapt in Arduino.h to uint8_t, too, please.

Regarding Arduino compatibility: https://github.com/arduino/ArduinoCore-API
Loads of unrewarding differences to merge, figure out, repair, refactor.