A while ago I had this problem where the People search results displayed in the ‘People Search Core Results’ web part & "Search High Confidence Results" web parts didn't show all the Skills from the User Profile. Only the last skill were returned from the search engine. I had the same behaviour when searching for people through the SharePoint search web service.
In the User Profile, as you can see below, multiple skills had been added to the SPS-Skills property. Notice that the last one is "Test Theory".
So when I did a serch for this user, I got the following XML output.
As you can see, only the last value was returned.
So what was causing this?
Well, after a lot of troubleshooting I found that this behaviour can occur if you edit the Skills Managed property using the Search Settings. When you edit this property or simply click the OK button on the Shared Services Administration: SSP > Search Administration > Managed Properties > Edit Managed Property > Edit Managed Property – Skills, the field "HasMultipleValues" within the SSP database table MSSManagedProperties, gets updated. By default the value for this field is 1, and it is updated to 0 even though this field does not map to any user editable properties on the SharePoint user interface.
Microsoft have confirmed this "issue", but do NOT consider it a bug. 
Update: Microsoft have changed their mind and now consider it a bug. No date for a QFE has been set.
Fortunately there's a way to reset HasMultipleValues to 1.
1. Create a custom dummy multivalue User Profile property and add it to the Skills Managed property.
2. Ensure that “Include values from all crawled properties mapped” is set.
3. Click OK.
Now the ‘HasMulitpleValues’ fiels is set to 1.
Do a full crawl. Executing the initial query again now returns all values from the Skills property.
Recently I noticed that I didn't get the expected search results when querying for data indexed through BDC.
The search term was System.ArithmeticException and I knew for sure that this term existed in the BDC datasource, but I got no results. I started investigating, but I'll spare you that story and instead tell you why this happened.
In order to get correct search behaviour you need to make sure that the same language specific wordbreaker is used both on query and indexing time. So if you're indexing English content your query wordbreaker should also be English. MOSS is using the browsers language settings to determine what wordbreaker to use.
On indexing time it's a different story. The iFilter checks if the text chunk from a document (or BDC source) has Locale info. If yes, it'll use the wordbreaker assosiated with that Locale.
If it doesn't contain Locale info (the BDC datasource didn't) the System Locale of the Index Server is used. In this case the Regional Settings on the Index Server was set to Danish, meaning that the BDC source was indexed using the Danish wordbreaker. Outch!!
I did a quick test and put the text System.ArithmeticException into a Word document and indexed it. No problem, I got hit on it when searching. I tried the same on a txt document. This time I didn't got a hit because a txt file doesn't contain Locale info.
Changing the Regional Settings to English and reindexing all content solved the problem...
Now you know what it means if the Regional Setting of your Index Server is NOT set to English. Of cource in some cases it might makes sense to set to something other than Ensligh, but not is this case.