If it’s not clear how to model a particular element in your model, try asking “which one?” If the question makes sense within your own scenario then you’re probably dealing with entities. If the question “which one” is meaningless in the context of your domain then you’re probably better off modeling the subject of the question as a value object.

I suggest that if you’re maintaining a collection, you implicitly care which one.

It is a mistake to attempt to maintain a collection of Value Objects.

Let’s take the near-canonical Address, a perfectly valid Value Object as described on page 98 of the Big Blue Bible:

public class Address : ValueObject<Address>
{
    public virtual string StreetAddress1 { get; set; }
    public virtual string StreetAddress2 { get; set; }
    public virtual string City { get; set; }
    public virtual State State { get; set; }
    public virtual string ZipCode { get; set; }
    public virtual Country Country { get; set; }
}

And a perfectly valid usage of this Address Value Object is as a component of an Entity:

public class Customer : Entity
{
    public Address WorkAddress { get; set; }
    public Address HomeAddress { get; set; }
    // ...
}

This, on the other hand, is incorrect:

public class Customer : Entity
{
    private readonly ISet<Address> _addresses = new HashedSet<Address>();

    public Address[] GetAddresses()
    {
        return _addresses.ToArray();
    }
}

Again, distinguishing addresses by maintaining a collection of them implies identity. If you tried to edit one of the addresses respecting some immutable Value Object oriented thinking, you would clear the collection, find (somehow) the one you intended to edit, replace it along with all the others.  This is not possible.  When you only care about the values of an object, rather than a key, you cannot find the original one you intend to edit from an instance of an edited object.  If you care about a key you have an Entity.

The original and the edited will never match. You might try to give the Value Object a database key so that it is easy to find.  But if you do that, why again are you clearing all the rest and re-adding them?  That doesn’t make sense – just edit it.

There’s another problem.  In the “wallet” example you have paper money in your wallet, several pieces of paper.  Your wallet is the Entity and the money is a Value Object.  If you were to take some money out of your wallet, you would subtract from the Value Object, not remove an instance of the Value Object from a collection.  You don’t care if you have five ones or one five, you just care that you have five.  Value Objects never collect, they only aggregate.

If you care about each individual instance, you have an Entity.

The best way to model something like this is to use an Entity that has a Value Object component.  If I am maintaining a collection of Addresses, I do actually care that each is different – the trick is to find out why.  In my case I care because the Customer has an address history and I wish to maintain that history.  I model that like this:

public class HistoricalAddress : Entity
{
    public Address Address { get; set; }
    public DateTime? Start { get; set; }
    public DateTime? End { get; set; }
    public AddressType Type { get; set; }
}

Now the HistoricalAddress Entity lives in the Customer Aggregate…

public class Customer : Entity
{
    private readonly ISet<HistoricalAddress> _addresses = new HashedSet<HistoricalAddress>();

    public HistoricalAddress[] GetAddresses()
    {
        return _addresses.ToArray();
    }

    public HistoricalAddress GetAddress(Guid historicalAddressId)
    {
        return _addresses.SingleOrDefault(x => x.Id == historicalAddressId);
    }

    //...
}

… and I am free to edit, list, and delete them with ease.

The one caveat is when you are maintaining a collection of Value Objects that represent all possible values.  If you have a State Value Object you may want to represent a collection of all 50 U.S. States as a select list in the user interface.  This works fine and is programmatically possible, until you are interested in maintaining this collection.