Catalyst Policy-Based Routing and Object Groups - Support?

[Twitch]

Hello all, if you are reading this, I hope you are well. 

I I am trying to figure out if Cisco Catalyst switches support referencing a Named Object-Group in a Policy-Based routing statement. The GNS3 lab I am in right now running iOSv Version 15.2(4 .0.55)E DOES NOT match traffic when referencing a Named Object Group. 
I have been unable to find specific restrictions between the two features. Can anyone enlighten me? Below is a sample config. 

### This groups all pilot sources into one reference, for ease of use and ACL config simplification####
object-group network SPS-Pilot-Sources-Group
host 10.1.X.14
host 10.1.X.18
host 10.1.X.34
host 10.1.X.119
host 10.1.X.124
host 10.1.X.131
host 10.1.X.12
host 10.1.X.251
host 10.1.X.43
host 10.1.X.2

### This groups all destination subnets for SBS Pilot. Again, ease of reference in the ACLs.####

object-group network SPS-Pilot-Dest-Group
10.1.X.0 255.255.255.0
10.1.X.0 255.255.255.0

#### This ACL is meant to match RDP traffic FROM Admin's PC 

ip access-list extended SPS-Pilot-Initiate
permit tcp object-group SPS-Pilot-Sources-Group object-group SPS-Pilot-Dest-Group eq 3389 log

### This ACL is meant to match REPLY traffic FROM DEV VLANS -TO- SPS-Pilot-Hosts

ip access-list extended SPS-Pilot-Replies
permit tcp object-group SPS-Pilot-Dest-Group eq 3389 object-group SPS-Pilot-Sources-Group log

#### These Route Maps override the routing table and forward the packets to the SPS Data Interface for both Initiates and Replies

route-map SPS-RM-Reply permit 10
match ip address SPS-Pilot-Replies
set ip next-hop 10.1.X.X
!
route-map SPS-RM-Initiate permit 10
match ip address SPS-Pilot-Initiate
set ip next-hop 10.1.X.X

[paul driver]

Hello

Can you confirm that you are wanting the replies from PBR RDP requests to be PBR'd back to another destination from its  source ip address?

[Twitch]

Hello Paul, thank you for the reply. 
Yes, the TCP replies must also go back to the PBR Next-Hop as well. 

Our PBR next-hop statement is sending all RDP traffic to a man-in-the-middle software solution for RDP (said software records entire RDP session, so it needs to be in the middle and transparent) This software is spoofing(source NAT) the originating clients IP when forwarding the RDP session, so when the destination host replies, it is replying to the original IP of the source client, which would be PBR'd back to the MITM RDP box. It does work flawlessly. However.... 

The issue is, imaging having to create ACLs for an enterprise Core switch PER VLAN SVI. Using traditional ACLs, the configuration would be monolithic. If anyone is Vlan 1 (/24) is trying to connect to another Vlan 10(/24), send to the MITM box. Well what if those users in VLAN 1 are ALSO trying to RDP to servers in VLAN 123? That is another ACL entry just on that SVI alone. Well what if the user needs to RDP to 10 VLANs or what if we have RDP users on 20 VLANS. The scale of these ACLs would be complex and inefficient. It's 2020 :P 

Hope this clarifies somewhat. I have a tendency to over explain. Using object-group ACLs on our core switch would dramatically ease the complexity of this configuration.  

Appreciate your time.