You can only have a single metadata with the same name belowing to one entity. So, the second create_metadata call does not create a new metadata entry but re-uses the existing metadata entry and overwriting the value. It's like doing

$entity->fruit = "apple";

$entity->fruit = "kiwi";

Now "kiwi" has overwritten "apple".

You could deal with the fruits as array and use implode and explode to convert the array to a string (as you couldn't save an array as metadata value). Or you could handle the fruits with entities (type would be object and subtype would be fruits). Entity owner would indicate who the fruits belong to. It all depends on what you have in mind later on with all the fruits on how to implement it best.

It really depends on what you have in mind how to implement it best. Would it make sense to use more than just a single metadata field to get it working? Entity type is object and subtype is product. And then you could have metadata "category" (on possible value would be "food") and the "subcategory" ("fruit", "vegetable" etc) and metadata "product_name" ("apple", "kiwi" etc.). There could be other metadata for products like "amount" and whatever might be useful.

A second type of entities could be used to handle an "order" made by a user (or whatever makes sense to be used as name for the choice of the users). And the selected items could again be handled for example by metadata referring to the guid of the chosen product. With every product handled with a single entity you have unique guids for every product. Another possibility would be to add a relationship between the order entity and the product entity. In this case you wouldn't have to deal with guids. But the relationship would only sign that a certain product would be part of an order but couldn't deal for example with the amount (how many kiwis?).