Spring Cloud Config Server does not serve application-specific properties in native mode

I have a Spring Cloud Config Server v3.0.5 which serves configuration properties from a Git repository like this:

|
|-- foo-service/
|   |-- application.yml
|-- bar-service/
|   |-- application.yml
|-- application-common.yml
|-- application-kafka.yml
|-- ...

As you can see, there is a sub-directory for each microservice that contains application-specific configurations and some common configurations in the root directory that we can fetch by profiles (common, kafka etc.)

So, for example, we can fetch application-specific and/or profile-specific config properties like this:

# Successfully returns application-specific properties
curl http://<CONFIG_SERVICE_URL>/foo-service-application.yml
# Successfully returns application-specific + common + kafka properties
curl http://<CONFIG_SERVICE_URL>/foo-service-application,common,kafka.yml

But, during development, we'd like to use a native file-based repository so that we don't need to commit every config change and test it locally easily.

So, in the config server, I've set active profiles to native and also set spring.cloud.config.server.native.search-locations to the same repository path.

But when I try to fetch application-specific configurations (i.e. config files in sub-directories), it returns empty:

# This returns empty response:
curl http://<CONFIG_SERVICE_URL>/foo-service-application.yml
{}

# This returns only profile-specific configs but **omits** foo-service applcations configs:
curl http://<CONFIG_SERVICE_URL>/foo-service-application,common,kafka.yml
...

What am I missing here? Why can't it also return application-specific properties? Do I have to set yet another configuration for the config server?

Any help is appreciated. Thanks.

OK, I finally found it!
Apparently, we need to explicitly specify the subdirectories with an application placeholder in the spring.cloud.config.server.native.search-locations property which is IMO vaguely described here in docs:

The search locations can contain placeholders for {application}, {profile}, and {label}. In this way, you can segregate the directories in the path and choose a strategy that makes sense for you (such as subdirectory per application or subdirectory per profile).

So, in my case, I had to define the search-locations as this:

spring:
  cloud:
    config:
      server:
        native:
         search-locations:
          - /path/to/config/repo
          - /path/to/config/repo/{application}

Now it can properly serve both application-specific and profile-specific config properties.

Although this suffices for my case, I still have no clue why the file-based and the git-based approaches differ so much (i.e. why should we explicitly set subdirectories for application-specific configs in a file-based approach whereas it can automatically serve them in the git-based approach?)