Views [commerce_customer_address-first_name] type replacement tokens don't work

I'm actually unable to reproduce this issue. It's been about 6 months, so maybe it's since resolved itself upstream? I went to the default Customer Profiles View in Commerce and rewrote the username field to use the [commerce_customer_address] replacement token and it worked fine. Added another instance of the Address Field to the View and used [commerce_customer_address-1] just fine.

However, I see you've mentioned these -first_name tokens - I'm not sure where they're coming from. Perhaps that's from the Addressfield Tokens module? When I look in the list of replacement tokens for my rewrite options, I don't see any hyphenated options (see attached image).

I'm going to guess this is a problem with a patch or other module on your site, but I will add that I intend to add full Token support to this module and will do what I can to test them within Views when they're added. #1188778: Add token support for the various elements of an address field

I'm having the same issue.
If you want to add both first and last names into views as separated fields you have to add 2 addressfields.
And other issue: if you want to enable sorting of firstname or lastname it won't work
See video: http://screencast.com/t/9ZWtXW89

I can confirm #2, and the workaround from the original issue proposal:

In the most recent release of Address Field, if you want to use the Rewrite functionality in Views for instance to output just the city/state components of the address, it does not work on the first address field you add to the Fields list. But if you set that one to "exclude from display" and add a second field, the rewrite works fine on the second field. On the first field you can display the full address, but if you use a rewrite like
[field_course_location_address-locality], [field_course_location_address-administrative_area]
the output is just ", ". Whereas on the 2nd field if you use
[field_course_location_address_1-locality], [field_course_location_address_1-administrative_area]
the output is something like "Seattle, WA" which is what we want to happen.

same here :)

Now that #991834: Address component Views support has been committed, is this issue resolved by using the distinct address field component Views fields?

Are you saying that we would need to add each distinct address portion to Views? It's a lot easier (if it worked) just to add the address field once and format it with a rewrite, rather than having to add about, let's see:
name of the location
address1
address2
city
state
zip
country

So you'd need to add 7 fields, set each one to "exclude from display" except the last one (or add an 8th field that is global text), and then do a rewrite on the last one or the global field to include all the pieces.

When semantically, really what you are trying to do is to "output the address with a custom format", which is to say, rewrite or reformat the output of the address field. So adding the address field once and doing a rewrite there, if it worked, would make more sense.

So I would say using the separate component fields would be a feasible work-around, but it's a lot more work in the UI to do it, so it would be nice if this worked.

The current work-around where you add the address field once and hide it, then actually use the 2nd one, also has been working for me.

@jhodgdon I'm not sure if you're testing in the context of Drupal Commerce or not, but if you were to install Commerce Kickstart 1.x (not 2.x) and import this View, you should see it working as you describe without the need for an additional hidden address field in the View:

$view = new view();
$view->name = 'customer_profile_addresses';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'commerce_customer_profile';
$view->human_name = 'Customer profile addresses';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Customer profile addresses';
$handler->display->display_options['use_more_always'] = FALSE;
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '10';
$handler->display->display_options['style_plugin'] = 'table';
/* Field: Commerce Customer Profile: Profile ID */
$handler->display->display_options['fields']['profile_id']['id'] = 'profile_id';
$handler->display->display_options['fields']['profile_id']['table'] = 'commerce_customer_profile';
$handler->display->display_options['fields']['profile_id']['field'] = 'profile_id';
/* Field: Commerce Customer profile: Address */
$handler->display->display_options['fields']['commerce_customer_address']['id'] = 'commerce_customer_address';
$handler->display->display_options['fields']['commerce_customer_address']['table'] = 'field_data_commerce_customer_address';
$handler->display->display_options['fields']['commerce_customer_address']['field'] = 'commerce_customer_address';
$handler->display->display_options['fields']['commerce_customer_address']['alter']['alter_text'] = TRUE;
$handler->display->display_options['fields']['commerce_customer_address']['alter']['text'] = 'Country: [commerce_customer_address-country]<br />
Administrative area: [commerce_customer_address-administrative_area]<br />
Locality: [commerce_customer_address-locality]<br />
Postal code: [commerce_customer_address-postal_code]<br />
Thoroughfare: [commerce_customer_address-thoroughfare]<br />
Premise: [commerce_customer_address-premise]<br />
Full name: [commerce_customer_address-name_line]<br />
First name: [commerce_customer_address-first_name]<br />
Last name: [commerce_customer_address-last_name]';
$handler->display->display_options['fields']['commerce_customer_address']['click_sort_column'] = 'country';
$handler->display->display_options['fields']['commerce_customer_address']['settings'] = array(
  'use_widget_handlers' => 1,
  'format_handlers' => array(
    'address' => 'address',
  ),
);

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'customer-profile-addresses';

The output looks like this:

I reproduced this without Drupal Commerce using just an address field on the user account and creating a similar View with rewriting. At this point, I assume this is either resolved in dev (perhaps unintentionally through the addition of better Views support?), in Views, or else is owing to some conflict on the sites reporting the issue.

The addition of better Views support solves the reason behind the original post (the desire to have separate address components in their own columns) and supports sorting per #2, even if we aren't sure that it directly fixed the presenting issue.

I'm happy to reconsider this if you experience the same behavior in -dev or can provide me with a Views export and give me entity / field configuration steps to make it work. Sorry this is so frustrating, but maybe it's just all gone and fixed itself. *fingers crossed*