Много благодаря! Обясненият регекс е лесен за схващане, но не мога сама да стигна до него, особено за времето на изпита. От понеделник го почвам, или го разнищвам, или никаква София. Като под "разнищвам" разбирам да ми е забавно, като трябва да го използвам, а не да отхвърлям цели задачи, защото не мога да си отсея input-а. :)

Специално за изпита мисля, че задачите могат да се решат и само с обработка със стрингове. Тази мисля, че също може - започваш цикъл отначалото на входното изречение като проверяваш дали текущия символ може да се парсне към число(try catch). Ако не може продължаваш напред като добавяш символите дотук в един StringBuilder. Ако се парсва проверяваш дали следващият също не се парсва, защото числата може да са от 0 до 20 по условие. Ако се парсва, повтаряш натрупаните символи дотук толкова пъти колкото числото и ги добавяш в StringBuilder за резултат. Ако имаш интерес, кажи и ще опитам да я напиша така този следобед.

Относно ученето на изразите, то при повечето хора е така. Това което на мен ми помогна най-много е поредицата на този човек като това е първото видео от нея(общо са 5-6 мисля за основните неща): https://www.youtube.com/watch?v=7DG3kCDx53c

Ако си добре с английския го погледни.

Може ли да погледнеш решението ми. Това, което казваш, се опитах да направя, но с метода char.IsDigit и с речници, не със StringBuilder , само че тестовете гърмят. Въпросът е защо? Защо try Parse хваща парсване към int, а IsDigit - не? Значи, почвам да я решавам вчера,  избирам какъв ще е алгоритъма - StringBuilder към момента ми е по-лесен от речниците, затова решавам - речници. И винаги съм готова да ги сменя, ако някой тест гръмне за памет. Но те гърмят за време, значи няма да ги оправя, ако сменя речника и листа със StringBuilder.Знам, че е най-добре с регекс, но засега ще е без него, знам, че нещо не правя както трябва с IsDigit, почвам да търся, попадам на  възможно решение с try Parse и зациклям. Защото за char.IsDigit във варианта IsDigit Method(Char) - както е в моя случай https://msdn.microsoft.com/en-us/library/7f0ddtxh(v=vs.110).aspx 

Return Value

Type: System.Boolean

true if c is a decimal digit; otherwise, false.

Така че, какво изпускам? Така или иначе после парсвам към int? Защо try Parse да парсва по-коректно?

Тръгвам да търся авторските тестове, които винаги са ми били краен УСПЕШЕН вариант. Не и този път. :) /Ти отварял ли си ги?/

Та така, описах  ти основните моменти от моята логика, ако можеш по-набързо да видиш къде бъркам, че на всеки му е ценно времето.

Ако промениш result да ти е StringBuilder, нпр., и след това му вземеш дължината с неповтарящите му се символи, /защото като лист не знам как да го преработя за достигане на същата идея/, :

var count = result.ToString().Distinct().Count();
Console.WriteLine($"Unique symbols used: {count}");

тогава ще получиш 100/100. Не мога да ти кажа защо, авторските тестове са прекалено дълги, за да разбера кой йероглиф се чете един път в result и два пъти в uniqueSymbols. :)

Всъщност, ако разбереш, моля пиши.

Да не би авторския да е грешен.

Щото и със сортед сет гърми на един тест и на един нулев, на същите, дето и със хаш сет гърми.

Ама няма символи, дето се повтарят на нулевия. Сортед сет ги сортира и се вижда, че са уникални. Съгласно дадения вход излиза, че авторския отговор на нулевия тест е грешен.

По вероятно е метода Дистинкт да е бъгав, защото, няма как сетовете грешно да преброят символ в повече. Това значи да изтърват два еднакви. Не може, защото или се хешират на едно място, или се сортират на едно място.

Затуй му се вика сет, защото по природа държи само уникални елементи.

Със Дистинкт.Каунт върху същия стринг билдър дава 100 точки, ама е грешно. Явно метода е бъгав.

Нищо не е бъгаво. Има уловка в условието че повторението може да е 0 - т.е. да не се включва. Затова трябва да се проверява крайният резултат за уникални символи, а не предварително.