Q:

emacs: help me solve this autoload ordering problem with flymake and csharp

How can I deliver a module that requires patching flymake, with minimal startup time (=autoload) and minimal impact on the user's emacs.el? 
I'm working on the flymake-for-csharp module. It works with flymake, teaches it how to be more flexible with C# code files.  For example, instead of just using a makefile, flymake-for-csharp can also use a .csproj file, or can invoke csc.exe directly. 
The module works fine.  I am now trying to make it autoload properly. 
here's the challenge.  
To define which languages get flymake'd, flymake.el includes a list of file extensions (.java, .cs, .c, etc) along with the init and cleanup routines for each of those languages.  There's an entry for C# in the default flymake.el, but as I said, the default C# behavior isn't flexible enough.  To make it more flexible, I need to replace the C# entry in the flymake alist, so that it points to the new init/cleanup logic in the flymake-for-csharp module.  Ya with me? 
It's no problem patching the alist at runtime.  It looks like this: 
  (let (elt
        (csharp-entry nil)
        (masks flymake-allowed-file-name-masks))

    ;; Find the existing C# entry
    (while (consp masks)
      (setq elt (car masks))
      (if (string= "\\.cs\\'" (car elt))
          (setq csharp-entry elt))
      (setq masks (cdr masks)))

    ;;  remove the original entry for C# ...
    (if csharp-entry
        (setq flymake-allowed-file-name-masks
              (delete csharp-entry flymake-allowed-file-name-masks)))

    ;; Now add a new entry for C#, with the custom init and cleanup methods.
    (setq flymake-allowed-file-name-masks
          (cons
           '("\\.cs\\'" flymake-for-csharp-init flymake-for-csharp-cleanup)
           flymake-allowed-file-name-masks)))

The long term solution is to persuade the authors of flymake and emacs to accept the logic that is currently in flymake-for-csharp. Then the alist will get the more flexible init/cleanup routines and bob's your uncle.  
But for now I want flymake-for-csharp to work with the existing (builtin) flymake.el.  Therein lies the problem: how can I make the flymake-for-csharp autoload, while still patching the alist? 
Ideally I'd like the user's emacs.el to look like this: 
(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

...with possibly a small (eval-after-load .. section.  
But you see, the function flymake-for-csharp-init would be called only after the flymake alist is patched to include the new entry for C#.  
Is there a way around this chicken-and-egg situation? 

one approach I thought of was to use (require 'flymake-for-csharp) in lieu of autoload.  Within that flymake-for-csharp module, run only the patch logic, and then use autoload, somehow, for the rest of the functions.  Would this be a good idea? Would this require me to deliver flymake-for-csharp in 2 distinct files?  
Another approach I thought of was to use an eval-after-load on flymake.el.  In that I could provide the patch function.  Couple questions with this:  

Would that work only if flymake is autoloaded?  What happens with the logic within an eval-after-load for a module that is already loaded when the (outer) eval-after-load is eval'd?  
how would I do this without impacting the user's emacs.el? 

In summary, 
How can I deliver a module that requires patching flymake, with minimal startup time (=autoload) and minimal impact on the user's emacs.el? 

A:

If I understand correctly, having the user add this to their .emacs would solve the problem:
;;;###autoload
(eval-after-load "flymake" '(code-that-patches-flymake-allowed-file-name-masks))
(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

Now, if you work with the folks using your package, you can use the loaddefs.el trick to get this code automatically loaded by the user by putting the ;;;###autoload comment right before the eval-after-load line in your package, and then rebuild the loaddefs.el file.
But, if you're hoping for a solution for general usage in the internets, you need the user to have both lines in their .emacs.

A comment on your cleanup code, I believe it can be simplified to:
(let ((csharpentry (assoc "\\.cs\\'" flymake-allowed-file-name-masks)))
  (when csharpentry
    (setcdr csharpentry '(flymake-for-csharp-init flymake-for-csharp-cleanup))))

