When working on ERC6982 I thought about batch locked events, but I dismissed it because it is hard to cover most cases. You covered the case when someone locks or unlocks a range. What if I want to unlock all the even tokenIds? What if I have 40 tokenIds that I want to lock/unlock in a single operation?
There are so many cases that can require a batch process and I believe that an ERC focused on batch processes should try to cover all of them.
For this reason, I would change the name of the event from BatchLocked to RangeLocked, which is more clear.
Instead of forcing users to implement many overlapping interfaces, it would be better to make an extension. Why not setting it as
// ERC165 interfaceId 0x75587558
interface IERC_Draft_BATCH_MIN_SBTS is ERC5192 {
/// @notice Emitted when the locking status for a range of tokens is changed to locked.
event BatchLocked(uint256 _fromTokenId, uint256 _toTokenId);
/// @notice Emitted when the locking status for a range of tokens is changed to unlocked.
event BatchUnlocked(uint256 _fromTokenId, uint256 _toTokenId);
}
If not, those who have already implemented ERC5192 will have issues using both interfaces.
In conclusion, I would suggest you change it in
//
interface ERC7558 is ERC5192 {
event RangeLocked(uint256 _fromTokenId, uint256 _toTokenId);
event RangeUnlocked(uint256 _fromTokenId, uint256 _toTokenId);
}
or (what I would prefer 
)
//
interface ERC7558 is ERC6982 {
event RangeLocked(uint256 _fromTokenId, uint256 _toTokenId, boolean locked);
}