Zephyr is an "OS" in pretty much every conventional sense. What you're saying, I think, is that a default build of Zephyr on a no-MPU device is a single shared .text segment where all the threads and other OS-managed objects are app-created by C code. So... sure, it's a library and an OS. And even when running on a system with an MPU/MMU, Zephyr tries hard to present that same API (i.e. function calls into the kernel become syscalls automatically, etc...), so the illusion is a fairly strong one.
And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it).
If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.
And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it).
If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.