Symfony version(s) affected: 3.4.41

Description
In short: When providing a string argument to a service that contains something that looks like a path (like '/var') it will (or could?) be replaced by some other path. If that part of the argument is not actually a folder-path, that replacement might be unexpected and lead to errors.

We try to use a SOAP API of an external service provider (DHL). In doing so, we configure the SOAP-URL (/ WSDL-URL) in our parameters.yml:

# This file is auto-generated during the composer install
parameters:
    ...
    dhl.wsdl: 'https://amsel.dpwn.net/abholportal/gw/lp/schema/1.0/var3ws.wsdl'
    ...

And provide that parameter to the SOAP-Client object in a service XML:

<?xml version="1.0" ?>

<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd"
>

    <services>
        <service id="app.dhl_soap_client" class="Foo\Bar\DhlSoapClient">
            ...
            <argument>%dhl.wsdl%</argument>
            ...
        </service>
    </services>
</container>

When building the cache, symfony creates the following cache file for this service:

<?php

use Symfony\Component\DependencyInjection\Argument\RewindableGenerator;

// This file has been auto-generated by the Symfony Dependency Injection Component for internal use.
// Returns the private 'app.dhl_soap_client' shared service.

return $this->services['app.dhl_soap_client'] = new \Foo\Bar\DhlSoapClient(..., ('https://amsel.dpwn.net/abholportal/gw/lp/schema/1.0'.$this->targetDirs[6].'3ws.wsdl'), ...);

Notice the replacement of the /var part in the URL with $this->targetDirs[6]. If we load that service, the following string argument is given to the object:
https://amsel.dpwn.net/abholportal/gw/lp/schema/1.0/mount/foo3ws.wsdl
That URL does not actually exist, causing the API call to fail.

I do not know which symfony-"feature" is responsible for this wrong behaviour, but I could identify the Symfony\Component\DependencyInjection\Dumper\PhpDumper (method export) class as the one that generates this code. I tried to understand why it does this replacement but failed at understanding the intention behind it.

How to reproduce

I currently do not have the time to provide a script to perfectly reproduce the bug, but i could hand one in later if it is actually needed. I think that one should be able to understand the problem using the explanation above.

Possible Solution

I do not have a possible solution because i do not understand the intention of the behavior that is happening here.