> how to exceed the normal limits on Linux kernel modules.

Uh, what limits? I'm not aware of anything that would stop your module, once probed, from reaching around the back of the kernel and futzing around in the internals of another driver/device in a completely unrelated subsystem, or subsystem internals. SoC/SoM vendors love to pull that kind of crap in their BSPs.

> hooks the VFS to allow dynamically remapping file paths on a per process basis

Instead of messing with kernel VFS internals, you could try:

- patching the offending application or package (ideally make the path configurable and contribute that back upstream)

- running the application in a mount namespace and bind-mount something over the path

- use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)

> use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)

I think I would literally recompile libc to patch fopen/open/openat long before I would even begin to consider writing a kernel module to mess with filesystem paths on a per-process basis.

I feel like if you find yourself seriously considering writing a kernel module then you are either contributing to kernel development, or have embarked on an adventure specifically to learn about kernel internals, or have take a very wrong turn.