I need to tell flist that the first argument is a scalar called flag, the second also a scalar called RLc, the third through 6th correspond to a 1D list of dimension 4 called cL, etc.

OK, we're almost there. I don't want constraints. I want to recover the original lists and pass them on to other functions that use them. So I think this does it:

av0 = {1., 1.};
a = Table[av[i][t], {i, 2}]; b = {{0.01, 0.02}};
apat = {x_, y_}; bpat = {{z_, w_}};
vars = a;
varex = Flatten[{a, b}];
varpat = Flatten[{apat, bpat}];
fImplementation[(*x_,y_,z_,w_*)Sequence @@ varpat] := 
  (a = {x, y}; 
   b = {{z, w}}; (1/2) (1 - a[[2]]) a[[1]]^2 + (1 - a[[1]]) a[[2]]^2 +
     a[[1]] a[[2]] - b[[1, 1]] b[[1, 2]]);
eqnlist = {Derivative[1][av[1]][t] == 
   Derivative[1, 0, 0, 0][f] @@ varex, 
  Derivative[1][av[2]][t] == Derivative[0, 1, 0, 0][f] @@ varex, 
  av[1][0] == av0[[1]], av[2][0] == av0[[2]]}
solDEsuper = 
 NDSolve[eqnlist /. f -> fImplementation, vars, {t, 0, 1.4}]

It's a bit unwieldy, but probably good enough. How can I pay you?

Sorry, I am not familiar with associations

Sorry for the distraction then. Associations aren't inherent to the problem you're trying to solve. I was just trying to demonstrate how to transform between representations.

I'll try to refactor your code later. I only have a couple of minutes right now. So for now, I'll just try to explain why it failed.

Here's your definition for fflat1 (I'm removing the comments for clarity)

fflat1[Sequence @@ Flatten[{flag_, LRc_, cL_}]] := cL[[1]]

If you look at just the argument list you created, it looks like this.

Sequence @@ Flatten[{flag_, LRc_, cL_}]
(* Sequence[flag_, LRc_, cL_] *)

So, your function expects exactly three arguments. But when you tried to apply it:

fflat1[Sequence @@ Flatten[{1, 0.1, cout0L}]]

you actually provided 6 arguments:

Sequence @@ Flatten[{1, 0.1, cout0L}]
(* Sequence[1, 0.1, 4., 4., 4., 4.] *)

When you applied it the other way:

fflat1[1, 0.1, cout0L]

you did provide exactly three arguments:

Sequence[1, 0.1, cout0L]
(* Sequence[1, 0.1, {4., 4., 4., 4.}] *)

but the last argument was itself a list. So, with the argument constraint satisfied, the function was evaluated to be the first item in the third argument, which is 4..

So, back to trying without lists in the args to ffoutsuper, since we Derivative has problems with lists in my real case, either being too slow, or trying to do nonsense like differentiaing the real part of a variable. This should not be complicated, but I don't know how to do it. I want to reconstruct the lists inside ffoutsuper. ffoutsuper gets a flat sequence, so the information of the list stuctures is lost to it, but not in my head. For each simulation I will have a constant list structure, though these will vary from simulation to simulation, and for now I don't mind rewriting code for different simulations.

So I know where in the flat structure to start and where to end, for reconstructing all the lists, no matter what shape they have. I just need a way to refer to the nth argument of the flat sequence in the args of ffoutsuper. Can you show me how to do that? Do I need to define a pure function and use Slot? Here is a failed attempt to reconstruct one of the lists for a simple example Wolfram Notebook

No need to pay.

I'm not confident that this is the final answer, but I just want to use this as a point of discussion to try to nail down where the disconnect is. What if we just used a purely formal symbol for the "non-analytical" function and then provided whatever implementation you want as a second function?

av0 = {1., 1.};
varex = Table[av[i][t], {i, 2}];
eqnlist =
  {Derivative[1][av[1]][t] == Derivative[1, 0][f] @@ varex,
   Derivative[1][av[2]][t] == Derivative[0, 1][f] @@ varex,
   av[1][0] == av0[[1]],
   av[2][0] == av0[[2]]}

(* 
  {Derivative[1][av[1]][t] == Derivative[1, 0][f][av[1][t], av[2][t]],
   Derivative[1][av[2]][t] == Derivative[0, 1][f][av[1][t], av[2][t]], 
   av[1][0] == 1., 
   av[2][0] == 1.}
 *)

And then,

fImplementation[x_, y_] := (1/2) (1 - y) x^2 + (1 - x) y^2 + x  y;
eqnlist /. f -> fImplementation
(*
  {Derivative[1][av[1]][t] == av[1][t]*(1 - av[2][t]) + av[2][t] - av[2][t]^2, 
   Derivative[1][av[2]][t] == av[1][t] - av[1][t]^2/2 + 2*(1 - av[1][t])*av[2][t], 
   av[1][0] == 1., 
   av[2][0] == 1.}
 *)

Or even this:

f[x_, y_] := (1/2) (1 - y) x^2 + (1 - x) y^2 + x  y;
av0 = {1., 1.};
varex = Table[av[i][t], {i, 2}];
eqnlist =
 {Derivative[1][av[1]][t] == Derivative[1, 0][Inactive[f]] @@ varex,
  Derivative[1][av[2]][t] == Derivative[0, 1][Inactive[f]] @@ varex,
  av[1][0] == av0[[1]],
  av[2][0] == av0[[2]]}

And then when you want your implementation to be applied:

eqnlist // Activate

Does that get us anywhere?

Okay, I think I see what you're saying now. I'll try to take a stab at it later. But in the meantime, here's the simplest thing I can think of to satisfy your suggestion to

take a list, turn it to a sequence before passing to f, then reconstruct it inside f, so that I can pass lists to other functions that I call from within f.

In fact, I'll show both "directions":

functionList[list_List] := dependencySeq @@ list;
functionList[{1, 2, 3}]
(* dependencySeq[1, 2, 3] *)

functionSeq[args___] := dependencyList[{args}];
functionSeq[1, 2, 3]
(* dependencyList[{1, 2, 3}] *)

inputList = {a, b, c};
functionSeq @@ inputList
(* dependencyList[{a, b, c}] *)

My intuition is that this is too simplistic to work, but without going back to look at eqnlist or ffoutsuper right now, that's the simplest thing that satisfies my best attempt to interpret your words here.

Not quite. Maybe somehow include g1 and g2 in the eqnlist. As it is now, the equation does not have the Derivatives (with respect to the list arguments, not time), and also eqnlist has done the evaluation symbolically of f, instead of keeping it unevaluated.

But you get the idea, right? One function to deal with lists and another to deal with sequences.

Okay, then I need more information. I can't tell the difference between this and what you had previously that I thought you said was good.

Is there anyway you can simplify the problem? Like just give a simple function whose derivative is just dead simple to look at and immediately recognize and then provide an actual correct solution that I can use as a test case?

I feel like we're getting lost in implementation details, and I haven't actually figured out what you really want.

Also, some commentary with your examples would be helpful. I'm not sure what's working as desired and what's not. You seem to set up an example just to indicate that it's not what you want, but it seems to work, so I don't know what the problem is.

Or maybe work backward. Hand-roll the entire NDSolve expression. Just provide the literal inputs that you want that work for NDSolve. Then show me what you have as inputs to this whole process. From there, maybe I can figure out how to get from your inputs to the final NDSolve expression.

so it it NOT what is needed.

Excellent! That's progress. So, what is needed?

Clearly we're having a communication issue. You think you've provided me with enough info, but I don't understand. Why can't you literally just manually change the thing that doesn't work to the thing that does work and show me that? If you do that, I can almost guarantee that I can show you how to get there.

As far as the derivatives, they have to have the same number of arguments as the function f. But I want to be able to have them applied in a systematic way to the list elements. So I will need something to convert the lists to sequences that I can pass to Derivative, while manipulating the lists.

In your third cell, why don't you just do the following?

f[a : {_Real, _}] := 0.5 (1 - a[[2]]) a[[1]]^2 + (1 - a[[1]]) a[[2]]^2 + a[[1]] a[[2]]

The only reason I want at least one of the elements of the list of arguments passed to f to be real, is a hack. I want to pass NDSolve a list of symbolic equations. Since f in my actual problem can't be symbolically evaluated, the Real qualifier prevents evaluation when the derivatives are taken (the ones with respect to the arguments of f, not the ones with respect to t), to produce acceptable (to NDSolve) symbolic equations. Once NDSolve gets going, it replaces the arguments by real numbers, and then f can be evaluated. This can be seen to work in the fourth cell, which does not have a list of arguments passed to f. But I need to have a bunch of lists passed to f in my real (meaning actual, not as in real vs complex vs symbolic) example.

Perhaps this could be done with Hold and Release as well (instead of the Real hack) but I have been so far unsuccessful in achieving that.

Thanks Eric for your help. I don't think I expressed what I need well, so your examples probably won't work. Here is a better explanation referring to the included notebook: The first evaluation cell has no problem because f1 and f2 are symbolically defined.

The second evaluation cell also has no problem because f1 and f2 are able to be symbolically evaluated in eqnlist, before being passed to NDSolve, by taking a symbolic Derivative of f.

The 3rd cell has a problem because I insist that the Derivative not be evaluated unless one of the arguments to f is a real number (instead of a symbol), which is the case once NDSolve gets going, but not initially. Though in this case f1 and f2 can be symbolically evaluated, in my real case they can't. If they are numerically evaluated before being passed to NDSOlve, then NDSolve will not get a list of symbolic equations. So they need to delay evaluation till NDSolve gets going (The real f is a conditional eigenvalue of a complicated large rank matrix that also depends on solving another ODE).

In the fourth cell, I show that as long as there is no list in the arguments of f, there is no problem with the same insistence on not evaluating eqnlist and keeping it symbolic so NDSolve is happy.

In the fifth cell, I try to convert the list to a sequence before passing to f, and then convert back to a list inside of f (It looks silly in this example, but in the real application keeping list structures is essential, there are many lists, they get passed on to other functions, and it becomes an unwieldy mess without them), but it doesn't work (I need to do the Extract while stripping the "Real" qualifier, I don't know how to do that yet)