"Authenticated Feeds" not usable with Nuget config-based credentials

I want to use a ProGet feed that requires authentication in my build process. I've added the credentials required to access the feed to NuGet.config. Build fails because if the fact that packages cannot be retrieved from ProGet. A little bit of investigation leads to the following problem:

NuGet relates configured credentials to the base feed url. So it can be used for authentication of the feed url (e.g. http://myserver/nuget/myfeed in ProGet or https://www.nuget.org/api/v2 for nuget.org). That's why the first step of a nuget package restore, retrieval of the package list works. For package retrieval from authenticated feeds, nuget looks if the configured feed url is base of the package url and if so, io uses the configured credentials. That works for nuget since here, feed url is base of package url (e.g. https://www.nuget.org/api/v2/package/anypackage/anyversion). You can see, the package url starts with the feed url and thus, nuget can use the configured credentials to pull the package.

In ProGet, feed url is not base of the package url (e.g. http://myserver/api/v2/package/myfeed/anypackage/anyversion) and thus, nuget will not use the configured credentials for authenticating the package pull ("http://myserver/nuget/myfeed" is not base of "http://myserver/api/v2/package/myfeed"). That's bad.

Two questions:

Is there a certain reason for having package urls completely different from the base feed url. Seems to be a bit uncommon.
Is there a workaround for the issue? Otherwise, ProGet is simply not usable for hosting authenticated feeds.

I'm using ProGet Enterprise 3.4.6

Product: ProGet
Version: 3.4.6

Is this the latest version of NuGet? I don't think we've seen this behavior before. Since we haven't encountered this, there's no workaround yet that I know of.

There's no real reason the URL's have to be different at this point. I believe in the past some distinction was made between the OData endpoint (the feed) and the NuGet API endpoint (package push/download URL), as they are technically two separate API's. Ironically, we were trying to be more compliant by separating them. We've simply had no reason to change anything until now.

Yep, the latest stable nuget 2.8.3 from 17. October 2014.

Meanwhile, I've created a private nuget.exe version that is aware of the proget behavior and this one works fine with private feeds. So I've found my workaround but of course still expect that proget changes to be compatible with official nuget releases in the future.

I have this same problem. I reported it to the Nuget forum in some detail (https://nuget.codeplex.com/discussions/578290) but didn't see much interest. Given the way that Nuget flows credentials it will be much easier to have the possibility to make the package download urls have the feed url as a prefix.
Is it possible to add this option to ProGet?

We'll be changing these URL's in the next release, which should be available by some time tomorrow.

Sounds great. Thanks.

Just want to confirm that the issue is fixed in ProGet 3.4.7.

Thanks!