Either add onto the scripts to also generate Bedrock's corresponding data files for porting the mod, or rewrite the scripts via a different system to generate both Java and Bedrock files.

For the bedrock stuff I have written a Java library which mimics older versions of Java edition and allows the resulting data pack to be generated. The Masonry bedrock builder could be adapted to import the master CSV file. The bedrock format has a lot of busy work and different file schemas required to build the addon so I don't think generating them as part of the powershell scripts is a good idea. For reference the Java code for building addons is at ~2k loc already.

The current version of the bedrock generator uses an enum for the materials, and an enum for the patterns, and then does a loop over both of them. The game plan was to have bedrock edition lag behind a bit as the general bedrock framework is limiting and does not allow for some of the features already implemented in the forge version, and some of the stuff Shadow has been planning. Maintaining a separate data set via enums is not very difficult and may even allow for greater flexibility over sharing the CSV data.

On my end of things I am currently missing data for the break speed, blast resistance, harvest levels, and map colors of each material. Not sure if those are implemented on the Forge end yet but having a separate sheet with that data would be nice to reference.

The blast resistance and hardness are in the spreadsheet because Java uses them in their block declarations. Break speed and harvest levels are just handled however Java handles them, not sure. I've just been mimicking the materials/colors from the base blocks the new blocks/slabs/walls are based on. They are in the master spreadsheet at the end of the lines, but I can definitely put them in a separate place if you wish as well. But yeah, for example, I just took the hardness/resistance from say Diorite and applied it to all Diorite blocks/slabs/walls.