Allowing split tunneling to combine with kill switch is a common request, and is pretty important for many people. Also an available feature of other VPN services. This is needed.

Turning off VPN for even a split second in order to access something on your local network significantly degrades the anonymity the VPN was providing you (all local apps get to phone home with the latest connection information, that data shared/sold/crossreferenced with other data obtained while connected to VPN, etc). I do not want a single packet leaving my phone/tablet unless it is protected by VPN -OR- going directly to a local subnet of an EXPLICITLY TRUSTED WiFi network. I want VPN protecting all traffic when at a coffee shop or airport public wifi, but I need local access to devices on my home network or while at a friends home or other explicitly trusted WiFi network.

"LAN Connections" mode is insufficient:
- Direct access to/from other devices while connected to public wifi networks is a bad idea
- I only want to allow my device access to the local network when I am connected to a WiFi SSID that I explicitly authorize local access for.
- I also need access to devices in different subnets of my local network outside of the DHCP IP pool assigned to WiFi devices.

"Split Tunnelling->Excluded IP addresses" is insufficient:
- Nearly all private and public WiFi networks reuse the same private IP address ranges, so all "Excluded IP addresses" that are (very likely) private network IP addresses will allow access to any devices at same IPs but on other WiFi networks. Unintended and unwanted access!
- Current android app version does not allow entries for an entire subnet, only specific individual IPs. I have many local servers/devices/IOT on my home network organized into different subnets with different firewall rules, some of them with dynamic IPs that I need access to while connected to my home WiFi SSID.

New Update to existing Features: "Per WiFi SSID subnet whitelist for VPN bypass"
- Kill Switch: Fully coexistant with Split Tunnel. If on, zero packets escape device unless it goes out over VPN, or allowed to bypass VPN with specific rules.
- Split Tunnel: Fully coexistant with Kill Switch.
- Variable length list of VPN bypass rules
- The simplest VPN bypass rule consists of a list of SSIDs and the associated VPN bypass whitelist of subnet(s) and/or Apps. These bypass rules only apply while connected to one of the explicitly listed SSIDs.
- For whitelist of subnet(s), convenience option for all official local IP ranges (10.0.0.0/8,192.168.0.0/16, etc) to bypass VPN -OR- use list of explicit subnets/IPs (for example 123.145.167.189,192.168.33.0/24, 10.12.0.0/16).
- For whitelist, could also include individual Apps, same as currently supported, but fine tuned for different SSIDs.
- If you want to get fancy: Standard-ish firewall rules with multi-interface outbound routing/NAT, or perhaps a simplified version of pfSense firewall rules? ;)

IDEAL USAGE SCENARIO from my point of view:
- "Set it and forget it" configuration, NEVER needing to toggle VPN/Kill Switch off
- Kill switch ALWAYS enabled, optionally of course
- VPN bypass for white list of public IP/domain names for direct connection (ie RAS for a tethered device, or services that block access from known VPNs)
- SSID-based VPN bypass for all private IP ranges while I am connected to my explicitly specified home network SSID(s), ie MyHomeWiFi + MyHomeWiFi_5G
- SSID-based VPN bypass for specified subnets while I am connected to explicitly trusted WiFi network SSIDs
- (to be clear, "home" SSID(s) are not specified, just a list of SSID(s) to apply a specific rule to)
- ProtonVPN app performing as a more general purpose rules-based firewall/router could be very interesting, but overkill for many people

Extra credit:
- VPN shared with tethered devices
- Traffic from tethered devices routed same as on-device traffic (ie same VPN bypass rules, etc)
- Tethered devices can communicate with each other (think peer-to-peer sync, data transfer, local webportal for admin, etc), while other traffic still routed appropriately
- Outbound packets from tethered devices should naturally have a TTL of 64.
- Un/Official association with GrapheneOS for advanced personal security and privacy features.