No, that API is still working as it is on AEM 6.5

To validate this situation, you can use the servlet resolver (http://localhost:4502/system/console/servletresolver) to better understand, how Sling is doing that resolution.  

Well, for me that feels like a bandaid for a different problem...

 resource=[JcrNodeResource, type=nt:unstructured, superType=null, path=/content/suncorp/businesspartners/en/home/reference-pages/policy-ref/rlg-nav/jcr:content/par/canvas/pars/content_container_1102807329]This the candidate.It's the node /content/suncorp/businesspartners/en/home/reference-pages/poli...

In the end, for testing purposes it's not different from a normal publish. Instead of configuring it behind the "publish" replication agent, you need to create a "preview" replication agent for it.

I don't think that this will work at all, in the end the bundle dependencies need to form a directed tree, and not a graph with cycles.

Why don't you use the replication API for this? 

You can have both at the same time  This is what we do with a customer. They have a lot of content, which is not changing frequently, and for which the classic invalidation is well suited. But they also have sections of the content, which need to expire very frequently, and for these we have a TTL c...

Yes, that user and its credentials is owned by Adobe.

But when you request that information from a publish instance, isn't the replication status always (and implicit) "replicated"? Because otherwise these CFS would not be present on a publish instance.