Antigamente no clipper, tinhamos a necessidade de criar indices composto porque era a unica forma de verificar se existia ou não determinada informação. Ou seja:

nome+UF

Agora, com o advento do SQL e rushmore, o a mesma procura tem o efeito em:

nome
UF

Pois o VFP vai sempre procurar todos os indices que podem ser usados em uma consulta.

Ok. Isso a gente já sabe ne? Agora vou especular :)

Use campos composto apenas se realmente o gargalo de uma aplicação for esta pesquisa, pois podemos fazer um questionamento:

Select * from cliente where nome=m.nome and uf=m.uf

Faz o VFP estabelecer a utilização de 2 indices o que nunca poderá ocorrer ao mesmo tempo (mesmo que sejam nanosegundos), assim ele primeiro vai pesquisar um indice, depois o outro e vai trazer os resultados da forma mais otimizada possivel.

Já

select * from cliente where nome+uf = m.nome+m.uf

Fará uma procura unica em um indice para que seja retornado apenas esta condição diminuindo a quantidade de ciclos usadas pela CPU e o HD.

Agora vamos aos pros e contras:

1) O indice composto é mais rápido, mas só funciona para um tipo de consulta específica;
2) O indice simples é mais flexivel mais exige mais espaço e tempo de CPU para consultar e incluir;
3) O indice composto é sujeito a mantenidade da aplicação, se um campo é incluido na pesquisa, o indice deve ser mudado tmb;
4) O indice simples pode ser usado pelo rushmore a qualquer momento sem que necessáriamente tenhamos o projetado para isso (uma pesquisa apenas pelo UF utilizaria ele, o outro indice não).

Existem outros pontos mais acredito serem estes os mais relevantes, vai depender do que sua aplicação realmente vai fazer, quantos dados vai manipular e qual a performace esperada por ela.

Claro posso estar falando um monte de besteira, mas acho que é assim que funciona. Que se pronuncie o pessoal que desenvolveu o VFP :P