Every time a function with a local-function is called, it allocates memory. In Steel Bank Common Lisp, such functions are "singletons", created once when JIT'ed, provided that it doesn't close over existing bindings. They are also pointer-equal in SBCL.

Please provide a "function" type distinct from a "closure" type to free the user from having to use methods or global functions in inner-loop code.

Record types should be able to be declared as a struct using an attribute.

It should be possible to mark all usages of a certain variable. The type of the variable is already inferred and shown when hovering over it. It'd be great if all places where the variable is used are highlighted, e.g. by setting a background color on the variable name. It'd be great if this is possible for several variables.

F# implements interfaces explicitly, causing excessive casting when working with or exposing classic C#-style interface heavy code.

The lack of intellisense support makes writing parsers and lexers more difficult than it has to be.

'a < x < b' means 'a < x && x < b'. (but x is evaluate only once)
Python implements this feature.

System.Threading.Tasks and Rx both support implementations of IScheduler. The ability to "parameterize concurrency" is quite powerful. The only options at the moment are selecting whether to use Async.Start on the ThreadPool or Async.StartImmediate on the current thread. Other options, such as an EventLoop or TestScheduler, are not available in F#.

improve the solution explorer for F# - let us expand .fs files to view types/modules and methods like you can in C# and every other "first class" language. In addition let us use the "search solution explorer" bar for F# types/symbols as well and improve the "goto xyz" support for C# -> F# and vice versa

Working with F#'s ref generic type is ugly. Too much need for (!val) constructs. Either increase (!) operator priority, or add C++-like -> operator, which would allow direct access through reference to its instance members.

Add a way of visualizing live (objects/functions/variables) in F# interactive. Possibly as simple as a PropertyGrid that shows active variables in memory. By adding the abiity to see what is in memory while using F# it becomes a VERY powerful data exploration tool. A few minor addtions of charting and grid output and this would be one of the best Data Mining tools available.

There are times that eg. F# value restriction could be solved with runtime dynamic code. C# has dynamic.

I wish F# could use dynamic as it uses mutable:
let I x = x
let dynamic F = II

abstract Users: ICollection<User> with get,set
default val Users = Unchecked.defaultOf<ICollection<User>> with get,set

member val is awsome but when a property must be virtual (such as a delay-loaded collection in Entity Framework) you have to switch back to the manual backing store.

If we allowed a "type" or "let" keyword to optionally follow an "and" keyword F# could allow mutual recursion between types and functions without adding any ambiguity to the grammar.

For a simple use case see http://stackoverflow.com/questions/7051672/f-is-mutual-recursion-between-types-and-functions-possible

F# compiler sometimes generates exceptions such as this:

L_001d: ldstr "Dynamic invocation of op_Explicit is not supported"
L_0022: newobj instance void [mscorlib]System.NotSupportedException::.ctor()
L_0027: throw

it incorrectly calls ctor() instead of ctor(String)

F# has a lot of tricky aspects that aren't well-documented.

One example is anything to do with the `inline` keyword:

* Member constraints and member invocation expressions.
* How dynamic and static type parameters interact, such as when writing a member invocation expression.
* What is the effect of the `inline` keyword on different sorts of members.

Another aspect is designing computation expressions using the custom operation attribute.

It would be great if there could be some more thorough documentation on these things. Sometimes it's really trial and error.

To be used like that:
items |> Seq.map $.Name