Section 13.1 - Scheduling issues (Stuart/Cadence) [Basic, System]
- interfaces allow non-deterministic behavior due to scheduling order
- need ability to control scheduling order

Interfaces provide plenty of opportunities for users to create non-deterministic designs (i.e. designs whose behavior is dependent on the scheduling order that a particular simulator happens to use.)

What are the rules and the capabilities that System Verilog will provide to enable users to create interfaces that do NOT result in non-deterministic designs?

For example: Can the user model the equivalent of non-blocking delays & delta cycles within interfaces? 
Can the user do the equivalent of signal resolution for multiple processes that simultaneously update the state of an interface?

Section 13.2.3 - Interface usage issues (Stuart/Cadence) [Basic, System]
- need to be able to specify and enforce rules about interface usage
- e.g., use of either Read or Write operation but not both
- e.g., limits on number of modules/processes invoking a given interface operation
- should be possible to define such rules in the interface itself without changing other code
- need to check rules in a way that allows for separate compilation
- need to be able to specify that some tasks/members of an interface are private

"Generic" interfaces allow a module to be attached to different interfaces, but they do not convey to the reader or allow tools to enforce that the module must be connected to an interface that implements a specific set of tasks or has specific members. As a simple example, there may be several different interface implementations of a FIFO -- one might gather statistics, another might not. In both cases modules that might be connected to such FIFOs should have an interface declaration that clearly specifies the set of FIFO operations that must be supported. E.g. write() but NOT read(), or vice-versa. Given the current proposed scheme, it can only be determined at elaboration-time whether an interface binding in a particular case is legal or not. Instead I believe it ought to be possible to determine this legality at the time a single module or interface is compiled.

It should be possible to do port registration checks for interfaces. For example, a user might want to implement a FIFO interface that enforces that it has exactly one module or process that writes to it, and exactly one module or process that reads from it. It should be possible for the designer to create such checks only within the interface, without forcing the code within modules attached to the interface to be modified.

In SystemVerilog today all tasks and members of an interface are available to be used by modules attached to the interface. This will inevitably lead to designs or models that use tasks or members of an interface that were never intended to be used externally. Therefore I believe that it should be possible to make certain tasks and members private so that they cannot be accessed externally.

Section 13.4 - Modports issues (Stuart/Cadence) [Basic, System]
- allow modports to be declared outside of interface/module, for reuse
- allow (modules and) interfaces to specify which modport(s) they implement
- import/export is confusing and unnecessary

It appears that Modports can only be declared within an interface. 
Why not allow modports to be declared outside of interfaces and modules, so that more than one interface implementation can implement the same modport? 

This would be a less error-prone solution than "generic interfaces".
The use of "import/export" within Modports is confusing and unnecessary.
Instead I believe that modports should be declared separately from interfaces, and the tasks that a modport makes available should be declared within the modport.
Then when an interface is to implement the tasks of a modport, it explicitly indicates this via a "implements mod_port_name" construct.
Similarly, since I believe that modules and interfaces should be equivalent, a module that wishes to make tasks available to other modules or interfaces will simply specify that it "implements some_mod_port_name".

Modules and interfaces should be able to implement multiple modports.

Of these two items, we are transferring the need to have both private and public variables for an interface to the Enhancement committee

We are also transferring the need for modports to be independent of interfaces (i.e. outside them). The idea is inheriteance of abstract base classes; separating the definition of an interface and the implementation of an interface.