pyscripter

Look at https://gitlab.com/teo-tsirpanis/gold-parser-Lazarus for a version 5 compatible Gold engine.  Version 5 grammars are not compatible with versions 1 engines.

But IMHO the good old lex/yacc https://github.com/RomanYankovsky/ndyacclex can be more easily integrated with your Delphi projects.   No need to rely on third party libraries.  One could develop and test the grammar with GOLD I suppose and then translate it to lex/yacc.

Please excuse my ignorance.  What is "New.Of"?

See Marco's blog post.

From the documentation: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/64-bit_Windows_Application_Development. 

Making Your Components Available at Design Time and Run Time
Following are the two ways the IDE decides whether or not a component is available for each platform. (Here "available" means appearing on the palette, and checked by the IDE. The IDE does not do any compile-time checking other than verifying the existence of component unit.)
Both methods described here rely on data embedded in the Win32 run-time (or design+run-time) package that implements the components. The IDE cannot load packages built for platforms other than Win32 in the IDE, so the IDE must defer to the Win32 package for information.

• The RAD Studio build system automatically embeds an RC_DATA resource in the Win32 package binary named PLATFORMTARGETS, which is a bitmask of the pidXXX constants in System.Classes.pas and reflects the package project's targeted platforms. The IDE reads this resource when the package is loaded and uses the resource data to decide, for example, whether or not to disable the component(s) in the palette when an unsupported platform is active.
  Targeting multiple platforms with a component package implies a contract between the component developer and the IDE. The IDE assumes that if a component package project targets multiple platforms and the developer distributes the Win32 run-time package to customers (and all the associated compilable and linkable files), the developer will also distribute all the necessary compilable, linkable, and run-time bits for the other targeted platforms as well.

• Individual components can use the ComponentPlatformsAttribute class attribute to override the data in PLATFORMTARGETS, using a bitmask of the same constants in the Classes unit. For example:
  type

   [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // Only supported on Win32 and Win64
   TMyComponent = class(TComponent)
   private
     ...
   end;

So to get the components to be usable with other plagorms, all you need to do is before you compile the Design package to add the other platform to it. They won't be used but just being there makes the build system to include the appropriate resource flagging the package as usable for the platforms. I have tested this and it works!