I agree, and have a couple of thoughts. Let me know how these align with your experience.

Situation 1 - Caching

On the caching item, I close and re-launch the Ops Console with the /clearcache flag. Have you  tried this?

Situation 2 - Old Scripts

On the 'using an old script', have you verified that the new MP has been recieved (event 1201 in the Ops Mgr Event Log) and workflows loaded (event 1210 in the Ops Mgr Event Log) on the affected system?

I see previous versions of my scripts running during the authoring process all the time, but it is usually because the new version of the MP has not yet loaded.

That is odd, and nothing that the /clearcache mentioned would actually fix in this case I don't believe. When I get into the lab this afternoon, I will try to duplicate and report my results. Looks like a possible UI bug to me.

for 2 - old script executed:

with sealed MP and not changing (increasing) version, we do not see the need to download MP to the agent. Unsealed MP is sent down every time.

I've seen this change group name behaviour in OpsMgr 2007 SP1 and R2 RC systems. The following is a simple test MP. Import the MP and there should be a group named CS Test AppName Group. Then change the name of the group in the MP and re-import. The name of the group will not change. Even deleting the MP from OpsMgr and importing will not rename the group

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <Manifest>
    <Identity>
      <ID>Computershare.Test.AppName</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>Computershare.Test.AppName</Name>
    <References>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Computershare.Test.AppName.Application" Accessibility="Internal" Abstract="false" Base="System!System.Service" Hosted="false" Singleton="true" />
        <ClassType ID="Computershare.Test.AppName.Group" Accessibility="Internal" Abstract="false" Base="System!System.Group" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Computershare.Test.AppName">
          <Name>Computershare Test AppName</Name>
          <Description>Test whether a System.Service "application" singleton can be renamed.</Description>
        </DisplayString>
        <DisplayString ElementID="Computershare.Test.AppName.Application">
          <Name>CS Test AppName</Name>
          <!--<Name>Computershare Test AppName</Name>-->
          <Description>First import of MP object has name "CS Test AppName". Second import name is changed to "Computershare Test AppName"</Description>
        </DisplayString>
        <DisplayString ElementID="Computershare.Test.AppName.Group">
          <Name>CS Test AppName Group</Name>
          <!--<Name>Computershare Test AppName Group</Name>-->
          <Description>First import of MP object has name "CS Test AppName Group". Second import name is changed to "Computershare Test AppName Group"</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>.

Yea, Tim McColl has reproduced it there perfectly.

I'm using Singleton Classes too, the problem is that it's not just a cosmetical problem, it's also a functional problem since I nest the groups against the Displaynames, and the Displaynames don't seem to be changing since the nesting doesn't work until I reapply. Of course I could change the targeting but that still doesn't solve the problem.

The funny thing is however, the Singleton Class condition may be true, but why does it all change once I manually reapply the Name?

And, also in the Authoring Pane under Groups it shows the old name (I guess this view doesn't use the Displayname Property then?)

And, why does OpsMgr not delete a Group when I tell it to. Same goes for Management Packs. When I delete something I want to get rid of it and don't want to have it cached somewhere in the background because it could be used the same way again ^^

If I have many changes to the names in the production environment, it will turn into quite a mess and I don't see the advantages of this concept.

In the OpsMgr Event Log you've verified the 1201 and 1210 events on that agent-managed computer verifying it has received the updated version?

It would be interesting to check the xml on these systems in the \health service state\management packs\ subdirectory to see if the new version of the script appears in the file.

With unsealed MPs, agents should pull down updated MP even if there is no version number change.