In the future, we're hoping to make it possible how the tilesets are arranged.
Here is the challenge. Only so many graphics can fit inside a bank. So once we start playing with user control, we need to start playing with different distribution of memory. Once we start dealing with different distribution of memory, we need to figure out ways for the game to declare which bank is paired with a screen. But since there is only a limited amount of data per screen, we don' t the bytes to allocate to that...so we need to re-factor something like how we handle collision tables, reducing the number of collision bytes (by having each be a nibble rather than a whole byte)...which means less tile types, and no *solid/ignore pathing* bits (which is why we've abandoned their use for this beta, anticipating that move coming soon), which then gives us more space per screen bank to potentially store more data, some of which could be bank for each portion of the graphic load...
This is why developing for the NES and its constraints is so crazy. It's not the graphical limitations or even the ASM language. It's the memory management that one just takes for granted in a modern development tool. It's the part we're most trying to keep users from having to think about.
So yes, it's planned for future to be able to not use path tiles, and even not use hud tiles...but we're still working on where to stuff the extra data needed to facilitate this.