While situation with writing (creating) udf 2.50/2.60 under Linux with only Open Source Software today is not much better than it was in 2010 * - some new development happens, and I found those links:
http://www.osta.org/specs/pdf/udf260_lastDraftWithChanges.pdf
6.17 UDF Media Format Revision History
(p. 159)
--------
UDF 2.50
FID File Identifier length and Unicode uniqueness
Disallow overlapping partitions
Strategy 4096 only for WORM media
UDF Unique ID Mapping Data
Extended Attribute block alignment
UDF Defined Named Streams section
File Identifier translation code repair
Correction of is_fileset_soft_protected rule
Disallow hard linked directories
Requirements for DVD-RAM/RW/R interchangeability
Unique ID for System Stream Directory
Shared description for some LVID and VAT fields
Recommendations for Mount Rainier formatted media
Recommendations for DVD+R and DVD+RW
Section 3.3.6 put out of order
UDF UniqueID clarifications
Clarify partition Access Type 3 and 4
Icbtag Parent ICB Location issue
Clarification of Volume Recognition Sequence
Metadata Partition Map
Partition Alignment & ECC Block Size Definition
Non-allocatable space stream usage clarifications
UDF 2.60
[...]
-------
https://sites.google.com/site/udfintro/
Apparently big problem with 2.5 support is 5.3.4 Metadata partition and further on 5.3.5 Pseudo-overwrite partition.
5.3.4 Metadata partition
Metadata partition is used to cluster metadata of the media together to get better performance. Metadata includes File Entries, allocation descriptors, directories, but does not include named streams or extended attributes.
The metadata partition lies on top of the underlying partition, which could be a type 1 partition, sparable partition, or a pseudo-overwrite partition. The metadata partition consists of 3 files: the Metadata File, the Metadata Mirror File, and the Metadata Bitmap File. The Metadata File and Metadata Mirror File have duplicated metadata -- File Entries and Allocation Extent Descriptors. They may optionally have duplicated data, i.e., each metadata has two copies on the media. To simplify the following discussion, we assume that the Metadata Mirror File does not duplicate the Metadata File content.
All data in the metadata partition are stored in the Metadata File. The logical block number in the metadata partition is the file offset in the Metadata File. Since some space in the Metadata File may be unused, the Metadata Bitmap File is used to keep track of the free space in the Metadata File. The metadata for the Metadata File, Metadata Mirror File, and Metadata Bitmap File are stored on the underlying type 1 (or sparable or pseudo-overwrite) partition. These are the only metadata that are not stored in the metadata partition. The data of the Metadata File and Metadata Mirror File must be aligned to the media ECC block size or packet size, whichever is bigger, and its size must be a multiple of the media ECC block size or packet size, whichever is bigger.
[....]
5.3.5 Pseudo-overwrite partition
The pseudo-overwrite partition (POW) is used for next-generation write-once media (e.g., Blu-ray Disc recordable or BD-R) on next-generation intelligent drives. These drives manage the address translation within the drive (what the virtual partition does before) to make the partition appear as an overwritable although the physical media is write-once. When POW partition is used, the metadata partition shall also be used for metadata, in the hope that metadata are clustered and achieve better performance. However, on write-once media, even when data are logically clustered in one partition, they may physically be far apart on the media. Because a longer physical distance often implies poorer performance, whether the use of metadata partition can improve performance is questionable.
In a media that supports POW partition, the media can be separated into several tracks. Each track has a Next Writable Address (NWA). A new block can be written to the NWA of any track. An existing block can be overwritten. The NWA of any track can change at any time. So NWA must be queried before any new block is written.
----------
https://github.com/pali/udftools/pull/7/commits - udf fsck, very ..experimental.
In the meaintime udftools saw release 2.1, with such changelog:
2.1
Latest release
2.1
af40587
Verified
This tag was signed with a verified signature.
@pali pali
GPG key ID: 8BF0C93D03E44352Learn about signing commits
@pali pali released this Dec 28, 2018
Changes in 2.1
Fixed compilation with glibc >= 2.25
Allow to compile without libreadline
Use pkgconfig for detection of udev rules directory
Set minimal version of autoconf to 2.64
Enforce ISO C99 compiler
Fixed support for big endian systems
Fixed converting strings to integers
Added support for UDF 1.50 Logical Volume Extended Information (contains volume label)
Added support for UDF 1.01 revision
Added workaround for Year 2038 Bug
udfinfo & udflabel:
Fixed accessing disks when MVDS and RVDS descriptors points to same location
Fixed support for disks >= 4GB on 32bit systems
Implemented reading VAT outside of outside of ICB
Various fixes for reading UDF descriptors
mkudffs:
Space optimization for small disks
Allow to set alignment of UDF structures via --packetlen option for any media type
Fixed alignment of VAT and generation of DVD-R and BD-R discs
cdrwtool:
Disallow specifying unsupported UDF revisions
https://k3b.kde.narkive.com/2HYlNTlJ/bug-257602-k3b-cannot-burn-blurays-or-avchds#post2
[Bug 257602] K3B cannot burn Blurays (or AVCHDs)
from 2018 posts it seems you can at least burn pre-formatted udf 2.5/2.6 image? (be aware about bugs)
* - https://irishjesus.wordpress.com/2010/10/17/blu-ray-movie-authoring-in-linux/