FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?

Question

I was trying to figure out why breakpoints were working fine for source files in some locations but not others.  FlashDevelop's debugger (which I believe is actually the FLEXSDK debugger) was successfully connecting, tracing output, and hitting breakpoints in SOME files, but not others.
I downloaded SWFInvestigator from Adobe Labs and checked the embedded debug paths for various source files to see what was going on.
I discovered that files in which no breakpoints could be hit had their paths embedded in all lowercase (e.g. "c:\users\username\desktop\source\myproject" instead of "C:\Users\username\Desktop\source\MyProject").
So I have two questions:
First, is this a Flex debugger issue, or a FlashDevelop plugin issue? Letter case shouldn't matter or interfere with matching file paths in Windows.
Second, what could possibly influence the letter case of embedded paths in a SWF output by Flash Professional (CS6), such that they are sometimes all lowercase and other times maintain the same case from the file system?  And why would that affect a debuggers ability to hit breakpoints in Windows 7?  I am compiling in multiple ways. Sometimes clicking Publish within Flash. Sometimes the file being published is not even open in Flash, and my JSFL script file is passed to Flash.exe containing embedded file paths to open the document. Usually, everything seems to work fine, no matter where I publish from, regardless of whether the FLA file is open or not. I'm honestly starting to believe that it depends on how the FLA was last opened in Flash Professional, as though it saves some sort of last access path internally and uses that to embed debug information.

Answer 1

I don't think it's the source path in my case, because it's simply the dot ".", although I did check that because it would most likely influence the embedded paths.
In the library path, I use relative paths exclusively, since all my individual project folders exist in the same "source" folder.
Here's how I arrived at the conclusion that something more complex or "stateful" must be occuring:
I publish my files with a one-click application, which does the following
updates version timestamps (static constants) in specific files via regex match
fills in a JSFL template with the FLA filename and writes the JSFL file to disk, then passes the JSFL file path to flash.exe for publication
the JSFL then runs a command, which signals the main application via cross-process communication that the script has finished publishing
That all makes it easy for me to update and publish multiple projects and deploy them, with a single click.  Here is the JSFL template I created, which has been drastically simplified since the days where it used to search to see if the file was open in Flash, select the document, and call publish.  Now it just uses the publishDocument method to silently publish files without opening them.
var filepath = "FLAFILEPATH"; //template parameter: the URI (beginning with "file:///") of the FLA file to publish
fl.publishDocument( filepath, "PUBLISHPROFILENAME" );
FLfile.runCommandLine("COMPLETECOMMAND");
The C# app replaces the strings in all caps with the actual values.  The COMPLETECOMMAND is actually populated with the application's own executable path, along with a "complete" switch, which lauches a 2nd instance, which handles the complete switch by broadcasting a signal over an interprocess channel and then terminates.  The main instance captures the signal, triggers a wait handle, and continues with publishing the next file.  Here is the core code for it:
private string fillTemplate( string fla_directory, string fla_filename, string publish_profile_name )
    string fileuri = "file:///" + Path.Combine( fla_directory, fla_filename ).Replace( '\\','/' );
    return EmbeddedResources.OpenAndPublish //JSFL template file embedded as string resource
        .Replace( "FLAFILEPATH", HttpUtility.JavaScriptStringEncode( fileuri ) )
        .Replace("COMPLETECOMMAND", HttpUtility.JavaScriptStringEncode( "\"" + Application.ExecutablePath + "\"" + " -publishcomplete" )) //call self with -publishcomplete switch to signal main instance's publishCompleteSignal
        .Replace("PUBLISHPROFILENAME", HttpUtility.JavaScriptStringEncode( publish_profile_name ) );
private static readonly string FLASH_PATH = @"C:\Program Files (x86)\Adobe\Adobe Flash CS6\Flash.exe";
public void publish( string fla_directory, string fla_filename, string publish_profile_name )
    Program.publishCompleteSignal.Reset();
    string template = fillTemplate( fla_directory, fla_filename, publish_profile_name );
    string curdir = Environment.CurrentDirectory;
    string tempJSFLfilepath = Path.Combine( curdir, "temp_script.jsfl" );
    File.WriteAllText( tempJSFLfilepath, template );
    Process p = Process.Start( FLASH_PATH, tempJSFLfilepath );
    Program.publishCompleteSignal.WaitOne( 30000 ); //timeout after 30 seconds
Here's where it gets interesting.  The FLAFILEPATH has ALWAYS been passed in as all lower case, yet this publication method has worked 99% of the time for hundreds of publish operations every day.  This applies to both the publication of the first SWC, which is referenced by the second published SWF (both were being published with lowercase paths), yet the paths for the main SWF were remaining in lowercase, while those in the referenced SWC were maintaining the correct case from the file system.
So there may be any number of things going on here.  SWCs may be published differently than SWFs, such that SWCs always have the correct letter case for debug source files, regardless of how the source FLA project was opened.  Ensuring the path passed to publishDocument uses the right case definitely fixes the problem, but it doesn't explain why it usually worked, despite having always been passing a lowercase string.  The only variable I can think of in all of this is Windows itself or Flash, such as whether the document was open in Flash at the time the silent JSLF publishDocument command ran, and how that FLA was last opened (via shortcut, via "recent documents" in Flash, via recent documents in Windows.  It has to be something, even if it's something as obscure as how the folder path was last accessed in windows, although I strongly suspect it's just how (in terms of path case) the FLA was last opened in Flash.
In any case, I'm happy that passing the right case to JSLF's publishDocument command fixes the problem, so I'm not going to spend any more time trying to figure out how opening the FLA in various ways could affect the embedded debug paths.  The only thing that should be done is to address how paths with the wrong case are handled when they do get embedded that way for whatever reason.  Perhaps the flex debugger should be updated to use case-insensitive matches in case-insensitive file systems, unless, perhaps, this is a FlashDevelop debugger issue after all.