The adjustment method mentioned above is no longer required as random tests have been cleaned up (already 2 years ago).
Unfortunately, the instructions remain unclear and incorrect method signatures are provided in the description.

Sometimes a simulation isn't the best way to solve a problem.

IonutArhire - I haven't considered your solution, so I don't know if your issue is ONLY the multiplication, but I did have a thought about how to go about doing the multiplication without access to a 132-bit integer. I would recommend using unsigned, but without giving any spoilers, there are 2 questions to consider. 1) Is there a way to detect whether an overflow has occurred?, and 2) Are the results of an overflow predictable. I believe the answer to both of those questions is yes, and therefore, there should be a solution in there somewhere. :D.

gullymiles - saying something is "not a correct solution" isn't very helpful..there are any number of reasons a solution might not pass a test case. The question is - the algorithm can be correct, but be missing one thing which is causing the test case to fail. Sure, if you don't account for the overflow, the ultimate solution isn't "correct", but that doesn't mean the algorithm doesn't work. I would argue that if the algorythm works, then the solution IS correct, but it may not be efficient enough or smart enough about computer limitations (in the case of overflow) to pass. If the problem is efficiency, that often means needing to find a different solution, but that doesn't mean the solution isn't correct, it could be correct but insufficient. But again, that's the way I view it and at that point, it is more a question of semantics, because you are absolutely correct that if the goal is to pass the kata, there is more work to do.

Note: Before anyone marks this as "spoiler content", realize that everything in this is about how to get around the problems in C# with the test cases...I am not actually suggesting anything here in terms of how to solve this kata.

I finally passed, but in order to do so, I had to do several things.

1. Any time an '|' appears at the beginning or end of an expression (either the string itself or something like '(|a)', I had to treat it like Reg.normal('|') since their generator didn't kick this out as a bad string.
2. I had to run the input through a string modification routine I wrote and will give below, which strips out sections of the string that are being ignored by the test case parser. ALL of these affected strings should be rejected and return null, but since they don't, I needed to adjust the input accordingly to be the way their test case generator was seeing it.
3. I had to run it a couple of different times as there are still some strings that are correctly getting rejected by the test case, but are acceptable once run through my adjustment routine. I do not know why these ones are being handled correctly while others are not (or I would have adjusted my routine). If the test cases in C# are ever corrected, I will remove these kludges from my code, but until then, all of them and my debug stuff is all in because I wasn't sure it would succeed again if I didn't immediately submit.

Here is the string adjuster I wrote if anyone else wants to use it:

public static string AdjustInput(string input)
{
string hold = input;
int closes = 0;
bool changed = false;
bool keep = false;
string maykeep = "";
string dokeep = "";
int orpos = 0;
for (int i = input.Length - 1; i >= 0; i--)
{
if (input[i] == '|')
{
if (keep) return hold; //3rd time, this will be rejected
if (maykeep != "") {dokeep = maykeep; keep = true;}
if (maykeep == "") maykeep = input.Substring(i);
}
if (input[i] == ')') {closes++; keep = false; maykeep = "";}
if (input[i] == '(')
{
keep = false; maykeep = "";
if (closes > 0) closes--;
else {input = input.Substring(0,i); changed = true;}
}
}

if (changed) input = input + dokeep;

return input;

}

Thanks - I assume this has come up before and he knows, but has made no effort to fix?? As far as I can tell, the only problems are with unmatched parens, but it doesn't always simply truncate, as you can see from my example above (seems to be affected by subsequent 'or's (|). BTW - I tried to modify the incoming string so I could end up with the answer the test case is looking for...may have to go back to that approach. I have quite a bit of time already invested in this...there should be extra honor if you have to figure out how to account for a bad test case algorithm :D. But it would be a shame to simply get nothing because the tests don't work.

The issue you and quite a few other people seem to be having is that you are looking for the highest place you could slide to and assuming that will result in the highest possible slide. Here is a simple example to illustrate:

1

2 1
1 1 9

Your method would get 1 + 2 + 1 = 4, but the longest slide is 1 + 1 + 9 = 11

all Cx versions are flawed. The translator never corrected them.

I tried truncating the input beyond unmatched parens, but that doesn't help. Here is a good example of the problem:
'xS$f*D?]rxyQE&M@.f /\M$YL6BYCl z}nbV s(!<PHn|cfGWn?iUIJOI9r!c9%x}QTDih-qu.?{ZhNPZ2i|^0HE63,e!&<"JMoJ/B\ You have this as "should be" the following. (('xS$f*D?]rxyQE&M@.f /\M$YL6BYCl z}nbV s)|(^0HE63,e!&<"JMoJ/B))'

So not only are you expecting a result with unmatched open parens, if there is an '|' somewhere after that, it appears to be picking up again at that point. I've looked over a number of my failed cases to see if there are any other issues I need to fix, but as far as I can tell, all of the issues I'm having are somehow related to this issue. I'm passing everything except the random strings tests.
Please fix or advise. Thanks. :D.

Working on this in C#. Instructions aren't too clear in general, but I'm passing all of the basic tests. I'm failing random string tests where there is an open paren '(' in the string, but not a matching close paren ')'. I am recognizing this as an error and returning nothing, but the test case seems to be expecting something.

Also - I had one test case where it started something like this "+5(S......" and the result said that it was expecing "(+5)" - literally those 4 characters and nothing else. That certainly isn't correct. That one was unusually and I'm not certain what else in the test case caused that. Usually when there are unmatched open parens, it doesn't get rid of things, but it's not really predictable either. Not sure what in the random string test case triggered this, but you may want to look at the random string test case and make sure they are properly handling parens... Thanks.