Collections as decorators: pseudo-code implementation proposal

Question

Meanwhile waiting for the answer on the question I would like to discuss the possible implementation plan/details or in general even answer how hard would be to implement the following and which tools/techniques are necessary for that:

(excerpt from the referred question):

Suppose you need to implement many (sub)types of collections. One of the aspects is storage-related: list, array etc, while the other is behavior-related: ordered, remove only, observable (the one that fires an event upon every change) etc.

Obviously (again), the requirement maps directly to the well-known Decorator design pattern, where the storage-related aspect (list, array) will be decorated by multiple behavioral (ordered, observable etc).

So far, I would like to propose some reasonably short implementation in (Java-like) pseudo-code, while asking if it's possible to implement the following in Java or C# or, if not, then in any other modern programming language:

Basic interface every collection must support:

interface Collection {
    [mutator]
    public void add(object o);

    [mutator]
    public void remove(object o);

    [accessor]
    public object get(int i);
}

Storage aspect:

List implementation:

class List : Collection {
    [mutator]
    public void add(object o) { ... }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Array implementation:

class Array : Collection {
    [mutator]
    public void add(object o) { ... }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Behavioral aspect:

Thread-safe decorator:

typename<T> : where T is Collection
class ThreadSafe : Collection {
    private T m_source;
    private object m_lock = new object();

    [mutator]
    public void add(object o) { 
        using (m_lock) {
            m_source.add();
        }
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Observable decorator:

class ChangeEvent {
    public Collection Source { get; private set; }
    public Method UpdateType { get; private set; }
}

interface Observer {
    public notifyChange(ChangeEvent e);
}

typename<T> : where T is Collection
class Observable : Collection {
    public Observer Observer { get; set; } // additional property
    private T m_source;

    [mutator]
    public void add(object o) {
        if (Observer != null) {
            var event = new ChangeEvent() { Source = this, UpdateType = GetCurrentMethod() };
            Observer.notifyChange(event);
        }
        m_source.add(o);
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Ordered decorator:

typename<T> : where T is Collection
class Ordered : Collection {
    private T m_source;

    [mutator]
    public void add(object o) {
        int idx = findProperPosition(); // assumed possible using the base Collection interface
        ...
        m_source.add(o);
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Read-only decorator:

typename<T> : where T is Collection
class ReadOnly : Collection {
    private T m_source;

    [mutator]       
    public void add(object o) { throw IllegalOperationException(...); }

    [mutator]
    public void remove(object o) { throw IllegalOperationException(...); }

    [accessor]
    public object get(int i) { return m_source.get(i); }
}

So far, the above is pseudocode only, but the goal is to enable the client code to construct many kinds of collections, so that each kind can combine exactly one storage aspect any number of behavior-related aspects. Would be pretty nice to be able to construct those composite types in compile-time and super-handy to generate those even at run-time.

The question is how (any modern programming language counts)?